Reverting 'stat.c' to original.

[iss000]

Removing the 'ugly' hack. 'stat.c' and print() function are OK.
The same issue (with printing strings passed as param) occurs also in 'objdump.c'.
My guess is that virtual registers are messing up with (some) zp variables.
Here: printed lines are overlapped and random wrong strings are displayed (i.e. 'kl' instead 'kB'):

The problem disappears when I comment out '-mlto-zp=32' line in 'mos-cpm65.cfg' file from the llvm-mos-sdk.

As result everything works fine:

[davidgiven]

This looks suspiciously like a llvm-mos bug that got fixed a while back --- certain relocations where being made incorrectly which resulted in the zp static data being copied from the wrong place, so any short string which was being cached in zero page was getting corrupted. Like \r\n. I can't find a reference, unfortunately. Try upgrading llvm-mos and trying again?

FWIW, I've just tried it on the Oric in MAME and stat works fine on my system without modification:

[iss000]

The issue is there - check closely the second column in your picture.
It's printed '2kri' instead of '2kB '.
Else I'm using always the last release of llvm-mos-sdk (now 9.0.1).

[davidgiven]

Something's broken in llvm-mos --- asm.com doesn't work any more. It's not at my end; I tried redoing a previously successful build on github, and it now fails: https://github.com/davidgiven/cpm65/actions/runs/7532135164

I wonder if this is related?

[iss000]

Something's broken in llvm-mos --- asm.com doesn't work any more. It's not at my end; I tried redoing a previously successful build on github, and it now fails: https://github.com/davidgiven/cpm65/actions/runs/7532135164

I wonder if this is related?

In my latest tests it seams that ASM.COM works.
The github auto-build reports an issue:
ALSA lib seq_hw.c:466:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory
but I'm not sure if this is the real problem.
Else on my local make +mametest I found that there is (somehow) a stored old mame-session in
~/.mame/sta/oric1/ which is loaded during test. I removed it and now asm test.asm... works fine.

EDIT: I've repeated the test with enabled option -mlto-zp=32 and indeed, mametest fails:

and the log is:

MAMETEST src/arch/oricon+mametest
fail
GENPC   userdata        0000FC7C
CURPC   userdata        0000FC7C
CURFLAGS        userdata        N.....
PC      userdata        FC7C
A       userdata        DD
X       userdata        01
Y       userdata        04
P       userdata        B0
SP      userdata        01F1
IR      userdata        8D

BTW, what is the point to use -mlto-zp option in mos-cpm65.cfg?

[davidgiven]

I've just found a nasty LLVM bug: llvm-mos/llvm-mos-sdk#306 It was causing the start of the heap to not be relocated, meaning that if the binary was loaded above 0x0200 (which it usually is) then it would overwrite some of the program. This was causing the garbage out of ASM.COM in the mame tests. Unfortunately it'll take a while before the change reaches the release version of llvm-mos.

[iss000]

Great news! I have some improvements for Oric and will open PR after I test all on real hardware.

[davidgiven]

That bug hasn't gone away. I finally found out what's going on this time: llvm-mos/llvm-mos-sdk#320

The good news is that your suggestion of turning off ZP LTO should work around this for now. I'll send them a PR.

[ivop]

Could this please be merged? Only LF is not how it's supposed to work.

[davidgiven]

Sorry, yes. Merging. This was left open because of the underlying linker issue. (It's not a problem with ZP LTO, but it's provoked by ZP LTO...)