ARM 2nd processor: regression introduced

[egrath]

Hi,

i'm running the Acorn C 2.01 on the ARM 2nd processor and there was a regression introduced some time ago. With version 4.19 of BeebEm, the compiler/linker no longer works (linker hangs).

Running the same on 4.03 works as expected.

How to reproduce:

• Use the scsi disk image from https://garm.twilightparadox.com/nextcloud/s/YsMKPeoi4GL97M4 which contains Acorn C 2.01A
• Run the following command:

*MOUNT 1
*LIB :1.$.LIBRARY
*DIR :1.$.ARM.BENCH
*cc -super -o hellow hellow

On 4.03 this produces a binary executable "hellow" after about 5 seconds. On 4.19 this hangs indefinetely.

[egrath]

Could narrow it down a little bit. The regression must have been introduced between 4.17 and 4.18 (4.17 working, 4.18 no longer).

Sidenote: The produced binaries ("Hello World", created with Acorn C 2.01A on 4.17) work on 4.19.

[chrisn]

Thanks, and sorry for the regression. I think there are two problems. There was a bug introduced in the ARM emulation, which I've fixed. But now it reports:

Norcroft ARM C (with debugger support) 2.01A Jul 14 1988
link: (Fatal) external symbol table in '$.arm.clib.o.ansilib' is out of date
Finished after 0.81 sec.

This is related to a more recent change to the RTC emulation, which needs a bit more investigation. See #111.

[chrisn]

I'm not familiar with the Acorn C compiler tools, do you know if there's a way to find out what date the linker is seeing in ansilib? Or do you have the original installation disks, so I could create a new scsi disk image?

[egrath]

No, not really familiar with Acorn C 2, but I have the original installation disk, it's attached to this post. Please note that in order to run the binaries from there, you need to adjust the load and execute address to 0x8000 for CC, FPE and LINK as they are primarily meant to run under early versions of Arthur for the Archimedes instead of the Brazil supervisor the ARM evaluation board uses.

ansicr2.zip

[chrisn]

Thanks. I get the same error after copying over ansilib from that disk. I've done a bit more experimentation, and it looks like the error occurs if the clock is set earlier than a timestamp in ansilib file.

The error goes away if I hard-code BeebEm to return 90 for the year as presumably the timestamp in ansilib is 1980-something. The RTC only allows 2-digit years, and the modulo-100 change we made in #111 means that the ansilib file looks newer than the current time.

So one solution could be to add more options to let the user control the date from the RTC, e.g., to return a fixed year that's user controlled.

Another option could be to patch the ansilib file so the date is 00, but I'm not sure exactly where the timestamp lives.

[chrisn]

BeebEm uses David Sharp's Tarmac emulator, which emulates some instructions that wouldn't have been present on the ARM evaluation system: MUL and SWP. So I'm not sure we'd expect the compiler to run. Strictly, it seems like we should fix those instructions to emulate ARM1 behaviour.

[chrisn]

BeebEm uses David Sharp's Tarmac emulator, which emulates some instructions that wouldn't have been present on the ARM evaluation system: MUL and SWP. So I'm not sure we'd expect the compiler to run. Strictly, it seems like we should fix those instructions to emulate ARM1 behaviour.

Fixed in 6436e38.