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.

[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.

[ZERICO2005]

I do wonder if using scf \ sbc hl, hl would also be a good compiler optimization too.

[ZERICO2005]

I did a test on 2025 March 22nd, and was able to write from 0xFB0000 to 0xFFFF7F without issue on my Ti84CE 5.4.0 (non-python with the faster ram)

[runer112]

It's nice to know that writing to that region has no issue on hardware. But keep in mind that it's the read behavior that's relevant to calloc, not the write behavior.