Optimize __TICE__ calloc

[ZERICO2005]

• ti.boot.memclear appears to be identical to bzero, so PREFER_OS_LIBC will cause bzero to alias ti.boot.memclear.
• made the calloc implementation for __TICE__ slightly faster.

[ZERICO2005]

Is it safe to use $EFFFFF? In other words, when does the $E40000 range end?

[runer112]

According to https://wikiti.brandonw.net/index.php?title=84PCE:Wait_States, $EFFFFF is the correct address for the upper end of this region.

Also according to that page, the range from $FB0000 to $FFFFFF is also all zeros. Could we use that to save a byte?

Suggested change

	; uses the all zeros address range $E40000-$EFFFFF on the Ti84CE
	ld hl, $EFFFFF ; HL = src
	lddr
	; uses the all zeros address range $FB0000-$FFFFFF on the Ti84CE
	scf
	sbc hl, hl ; HL = src
	lddr

Note that there's also a comment near the top of the file that should be updated to match (or simply removed).

[ZERICO2005]

$FFFFFF is used for debugging in CEmu. $FB0000 and $FC0000 are used for the debug console log

[ZERICO2005]

It also looks like that only the range $FF0000-$FFFFFF (65536 bytes) has 1 wait state, while the rest of the range has 2 wait states

[runer112]

$FFFFFF is used for debugging in CEmu. $FB0000 and $FC0000 are used for the debug console log

Ok, so those certainly need special behavior for writes, but it doesn't seem like that functionality would require special behavior for reads. Do they not still read all zeros?

---

It also looks like that only the range $FF0000-$FFFFFF (65536 bytes) has 1 wait state, while the rest of the range has 2 wait states

Doesn't seem like a problem to me. The heap is barely larger than 64 KiB. Worst case, calloc'ing the whole heap (although what's even the point of dynamic memory allocation if you allocate the whole thing in one block) takes something like 286k cycles instead of 280k cycles.

[ZERICO2005]

I think we did do some tests awhile back to see if it was safe for boot_sprintf (formerly called ce_sprintf/ti_sprintf) to write to the $FB0000-$FFFFFF range. I can't remember but I believe writing to $FFFF00 was safe. Not sure if we tested further

[ZERICO2005]

$FFFFFF is used for debugging in CEmu. $FB0000 and $FC0000 are used for the debug console log

Ok, so those certainly needs special behavior for writes, but it doesn't seem like any of those would require special behavior for reads. Do they not still read all zeros?

---

It also looks like that only the range $FF0000-$FFFFFF (65536 bytes) has 1 wait state, while the rest of the range has 2 wait states

Doesn't seem like a problem to me. The heap is barely larger than 64 KiB. Worst case, calloc'ing the whole heap (although what's even the point of dynamic memory allocation if you allocate the whole thing in one block) takes something like 286k cycles instead of 280k cycles.

I think reading or write to $FFFFFF or $000000 does give warnings to the CEmu debug logs for "possible nullptr dereference". But yeah you were good to point out how we are only reading and not writing anything.

[runer112]

I'm not seeing any messages in CEmu's console after executing either ld a, (0) or ld a, ($FFFFFF). And the latter loads 0 into a.

[runer112]

Here's all the relevant CEmu code for reading from an unmapped port: https://github.com/CE-Programming/CEmu/blob/73a4cb0c1ae2a9d5c8d70ccb5f02c5705ad1871b/core/mem.c#L703-L714. The value variable isn't stored to at all, leaving it at its initial value of 0. There's no special behavior to support debugging. Only writing has special behavior.

Here's the only instance of the string "dereference" in CEmu: https://github.com/CE-Programming/CEmu/blob/73a4cb0c1ae2a9d5c8d70ccb5f02c5705ad1871b/core/mem.c#L754. This console message is only generated when performing an unprivileged write to flash memory.