Hi

(I'm new to this list so please forgive me if i'm asking questions that have already been answered elsewhere, and just point me to the right direction)

Inspired by some thread on the atari-forum (https://www.atari-forum.com/ viewtopic.php?f=16&t=41476&sid=cd858e109f7cd4f1cae6c597ea35b66f ) i recently tried to cross-compile freepascal for atari (using linux as host), and encountered a few problems. First off, a guy pointed me to the nightly build page (which i could not find btw. on the freepascal home page). That one also includes atari binaries which don't seem to be available elsewhere, but they are somewhat broken. All of the executables (not only the compiler) have $0c set in the program flags. The $08 bit of that value is interpreted by MiNT to allocate only a minimum TPA (which is the memory needed by the text+data+bss sections), but the startup code of fpc tries to increase that in order to allocate the stack. That causes all of the binaries to immediately fail with an out-of-memory error.

The next problem is the way the assembler and linker are invoked. I realize that in the daily builds, vasm/vlink are used, but i would really prefer to use gas/ld instead (which are also the defaults if you don't use -Avasm). When generating the cross-compiler, they are invoked as m68k-atari-as and m68k- atari-ld, however the standard binutils for atari are actually named different (m68k-atari-mint-as and m68k-atari-mint-ld). As a workaround, i now created symlinks for these, but this should actually be fixed. Also, the commandline for the linker is wrong in that case, it is invoked as

m68k-atari-ld -d -n -o <exe> <scriptfile>

where scriptfile is a generated linker script. That is missing the -T switch, which causes ld to accept <scriptfile> as object-file to link (and causing it to core-dump).

Another thing: that linker expects the first object to start at text address 0xe4, not 0. That is normally achieved by some statements in the script, but those are missing.

A thing that is definitely missing is support for the ARGV argument passing. Without this, commandlines are limited to 126 chars, and tools like fpc.ttp are not able to locate their own directory (needed for example to find the fpc.cfg file). If you want, i can try to implement that.

Hi,

very unlikely, since we implemented that atari interface there was little feedback about it ;)

We both (Charlie and me) are Amiga users, so not so used to the Atari stuff, so very likely something is wrong.

yes the Atari version is compiled by Jenkins every commit https://build.alb42.de:8081/job/FPC_m68k-atari/ (to make sure the changes does not break the target) it uses the command line:

make zipinstall OS_TARGET=atari CPU_TARGET=m68k 'CROSSOPT=-Cp68000 -Avasm -XV'

Since the Atari interface was implemented there was a little bit reaction to it, but not very much, so I don't think the the compiler was ever tested or used on actual Atari (I just compile them to make sure they don't break)

The main work on this was done by Charlie (I'm really more an Amiga-user, he is more like a retro computer guy), I'm not sure he reads here, so I will trigger him later to check it out, I'm sure he is happy if someone wants to help and improve it.

btw. you know this:

https://blog.alb42.de/2017/06/18/do-it-online-atari/

http://home.alb42.de/fpatari/

the prefix $CPU-$OS is just the default prefix for every cross compiling, if you need an other, you can supply it with e.g. -XPm68k-atari-mint-

I guess, because we use vasm and vlink the gnu as/ld is not properly implemented atm. At least for Amiga vasm and vlink work much better than gas/ld, not sure about the situation on Atari.

I think you can just do that and make a pull request on Gitlab.

Greetings,

Marcus "ALB42"

Hi Marcus,

thanks for your answers.

yes the Atari version is compiled by Jenkins every commit https://build.alb42.de:8081/job/FPC_m68k-atari/ (to make sure the changes does not break the target) it uses the command line:

Yes, i saw the console output already. What i could not figure out yet: where does the script come from that is executed by Jenkins?

Uh no, i did not know this. Awesome. Ultimately, it would be nice of course to run the resulting executable in some online emulator like pce-js ;)

the prefix $CPU-$OS is just the default prefix for every cross compiling, if you need an other, you can supply it with e.g. -XPm68k-atari-mint-

Yes, found that already. But there is also at least one assembler file that is directly compiled from the Makefile (prt0.as), and that is also compiled by that $CPU-OS-as assembler (also when you otherwise use vasm). So i wonder a bit why that works on your build server. I also noted that, when using vasm/ vlink, those are also executed using that prefix, so the actual assembler that is invoked is m68k-atari-vasmm68k_std.

One reason why i would prefer gas is because FPC needs a non-standard version of vasm (compiled with std syntax module instead of motorola), and that assembler is also required on the target system. But the name "vasmm68k_std.ttp" does not fit in the 8.3 filesystem limit on Atari.

With the symlinked assembler/linker, and some fixes to the generated scripts, i was able now to produce the binaries. I noticed though that they are much larger (maybe because that smartlink feature is not available). However currently most of them bomb out right at the start, have to figure out yet whether that is caused by the different linker, or some other change to fpc itself.

Thorsten Otto via fpc-devel schrieb am
Di., 25. Jan. 2022, 10:54:

For the makefiles you need to set BINUTILSPREFIX=m68k-atari-mint- then. This will be used both for assembly files and passed on to the compiler using -XP.

Regards,
Sven

Hi Thorsten,

hmm what do you mean? I wrote it, of course.

haha sure, but my knowledge of such things is too limited to really do such things, but if someone is interested, I happily share the source of this one.

If I remember right (for amiga, its that way so I guess also applies to Atari), that is because this old ld does not support section linking only object linking, newer ld support that but they can't be compiled for m68k anymore, therefore the linker can't throw away unused sections of the object file (only whole unused object files) and therefore the files are much bigger.

That was one of the reasons we changed to vlink because the coder of that implemented that for us.

https://blog.alb42.de/2017/01/07/small-is-beautiful/

If I remember right, it is possible to freely mix assembler and linker on Atari, so you can use gas and vlink for example.

Greetings,

Marcus

CET Sven Barth wrote

For the makefiles you need to set BINUTILSPREFIX=m68k-atari-mint- then

Thanks. I'm sure that i already tried that, and it did not work. But maybe i did something wrong, trying it again (without the symlinks) seems to work.

That still leaves the question why it works for the build server, without setting BINUTILSPREFIX.

Hi,

because it has symlinks for it:

ls -lasi /usr/bin/m68k-atari-* 4860751 0 lrwxrwxrwx 1 root root 27 Nov 17 2017 /usr/bin/m68k-atari-as ->
/usr/bin/m68k-atari-mint-as 4860752 0 lrwxrwxrwx 1 root root 27 Nov 17 2017 /usr/bin/m68k-atari-ld -> /usr/bin/m68k-atari-mint-ld 4860753 388 -rwxr-xr-x 1 root root 395928 May 3 2012
/usr/bin/m68k-atari-mint-addr2line 4860754 412 -rwxr-xr-x 1 root root 420444 May 3 2012 /usr/bin/m68k-atari-mint-ar 4860755 704 -rwxrwxrwx 1 root root 716924 May 3 2012 /usr/bin/m68k-atari-mint-as 4860756 384 -rwxr-xr-x 1 root root 391608 May 3 2012
/usr/bin/m68k-atari-mint-c++filt 4860757 452 -rwxr-xr-x 1 root root 462168 May 3 2012 /usr/bin/m68k-atari-mint-gprof 4860758 584 -rwxr-xr-x 1 root root 596732 May 3 2012 /usr/bin/m68k-atari-mint-ld 4860759 584 -rwxr-xr-x 1 root root 596732 May 3 2012 /usr/bin/m68k-atari-mint-ld.bfd 4860760 396 -rwxr-xr-x 1 root root 404472 May 3 2012 /usr/bin/m68k-atari-mint-nm 4860761 560 -rwxr-xr-x 1 root root 569656 May 3 2012 /usr/bin/m68k-atari-mint-objcopy 4860762 716 -rwxr-xr-x 1 root root 729272 May 3 2012 /usr/bin/m68k-atari-mint-objdump 4860763 412 -rwxr-xr-x 1 root root 420444 May 3 2012 /usr/bin/m68k-atari-mint-ranlib 4860764 388 -rwxr-xr-x 1 root root 395896 May 3 2012 /usr/bin/m68k-atari-mint-size 4860765 388 -rwxr-xr-x 1 root root 395864 May 3 2012 /usr/bin/m68k-atari-mint-strings 4860766 560 -rwxr-xr-x 1 root root 569656 May 3 2012 /usr/bin/m68k-atari-mint-strip 4860767 0 lrwxrwxrwx 1 root root 21 Nov 17 2017 /usr/bin/m68k-atari-vasmm68k_std -> /usr/bin/vasmm68k_std 4860768 0 lrwxrwxrwx 1 root root 14 Nov 17 2017 /usr/bin/m68k-atari-vlink -> /usr/bin/vlink

Greetings,

Marcus

CET Marcus Sackrow wrote

hmm what do you mean? I wrote it, of course.

But is that a script that is stored somewhere, or is it just a setting inside your Jenkins installation?

newer ld support that but they can't be compiled for m68k anymore

Yes, a.out support (which is used on Atari) has been dropped in 2.31. But i've added it back in, and cross-binutils of 2.34 can be found at http://tho-otto.de/crossmint.php#binutils

That does not mean that the section based linking will work. I'll have to check whether that can somehow be supported.

If I remember right, it is possible to freely mix assembler and linker on Atari, so you can use gas and vlink for example.

Yes, but when i use gas, i think fpc won't generate the required section directives?

ie. when using -Avasm:

.file "system.pp"
# Begin asmlist al_pure_assembler

.section .text.n_system_$$_get_caller_addr$pointer$pointer$$pointer,"awx" .balignw 4,0x4e71
.globl SYSTEM_$$_GET_CALLER_ADDR$POINTER$POINTER$$POINTER SYSTEM_$$_GET_CALLER_ADDR$POINTER$POINTER$$POINTER: link.w %a6,#-4
# CPU 68000
move.l %a0,%d0
tst.l %d0
beq .Lj1800_1
move.l %d0,%a0
move.l 4(%a0),%d0
.Lj1800_1:
# CPU 68000
unlk %a6
rts

Without it:

.file "system.pp"
# Begin asmlist al_pure_assembler

.text
.balignw 4,0x4e71
.globl SYSTEM_$$_GET_CALLER_ADDR$POINTER$POINTER$$POINTER SYSTEM_$$_GET_CALLER_ADDR$POINTER$POINTER$$POINTER: link.w %a6,#-4
# CPU 68000
move.l %a0,%d0
tst.l %d0
beq .Lj1800_1
move.l %d0,%a0
move.l 4(%a0),%d0
.Lj1800_1:
# CPU 68000
unlk %a6
rts

Hi,

Thorsten Otto wrote

Yes, a.out support (which is used on Atari) has been dropped in 2.31. But i've added it back in, and cross-binutils of 2.34 can be found at http://tho-otto.de/crossmint.php#binutils

Won't really help. As you found out already, section smartlinking won't work with a.out. It never worked in any version of binutils on any platform. Actually I went the vasm/vlink route, because the AS/LD versions I found online at the time I worked on the port, crashed hard on me on EmuTOS/Hatari, and vasm/vlink just worked. Plus the vasm/vlink combo supported section-based smartlinking. This is something actually I requested from Frank Wille to be added to vlink, and he was nice enough to add it for us. It's used on Amiga, Atari, and the Sinclair QL. Just for reference without some kind of smartlinking, we'd end up having a 300K-ish hello world... Instead of 25K-ish... So yeah.

(We do support individual .o/.a based smartlinking too, that should work for Atari as well, but you'll literally end up growing roots, it's so slow, I promise. So it just wasn't practical...)

That does not mean that the section based linking will work. I'll have to check whether that can somehow be supported.

I based on my experience with customized binutils, recommend against fighting with this. I'd much rather just generate an ELF binary, where all the shiny features are available and tested, then convert it with some tool to a native binary for the target. Actually we have several platforms which do this or something similar already. If I'm not mistaken, GCC for Atari used to have some tool like this? Brownout, maybe?

Yes, but when i use gas, i think fpc won't generate the required section directives?

This is intentional. FPC knows that GAS for Atari uses a.out (or used at the time, when I wired this together), and avoids generation sections, because they just didn't work (they didn't even compile back then).

Anyway, all of this is 2017-18 wisdom, or so. I haven't looked into your updated binutils yet, so feel free to correct me regarding it, if something which hasn't been supported before now is. :)

Cheers,

Thorsten Otto via fpc-devel schrieb am
Di., 25. Jan. 2022, 13:03:

Can it be that you forgot to write some reply here, Thorsten?

Regards,
Sven

Hi,

yes, thats how jenkins work usually, it comes with an building editor to write the script. But the script is not very fancy or complicated.

It's just that "make" line and afterwards copy the archive to webspace and copy some other stuff for the online compiler

at the end cleanup to save space

Greetings,

Marcus

CET Sven Barth wrote

Can it be that you forgot to write some reply here, Thorsten?

Hmpf, dunno what happened, so once again.

If I'm not mistaken, GCC for Atari used to have some tool like this? Brownout, maybe?

Yes, but i never used that "brown" tool. For one, i don't like its confusing naming convention (depending on gcc version, it is "brown", "extrabrown", "superbrown" etc). But more importantly, it needs an extra tool to be run after linking, which requires Makefiles to be changed for all projects that use it. That rules out most unix packages, where the Makefiles are generated by autoconf, Cmake or similar. Also the whole toolchain requires a script to be run on the mintlib (atari c-library) headers, which fails almost everytime something in mintlib changes. And they did not even manage to provide a gem library, or even a math library.

An alternative could be to use my mintelf toolchain, which is also available on my site. This is based on the same sources as the normal toolchain, but can be used as dropin replacement (just using a different target, or BINUTILSPREFIX in our case). It will generate working executables in the same way, but uses elf object format for compiling and linking, thus making all the features of that format available. For fpc that would mean however you have to tell it somehow that it can use elf features like sections, even when using gas. I will give it a try at the weekend, i think fpc can be tricked by using -Avasm, but then replacing the symlinks to the assembler.

If all else fails, i'm of course also ok with using vasm/vlink. There is only the problem of the too long filename of the assembler executable. That should be fixed i think, because it is also needed when running the *.ttp on TOS. And of course i have to find out what causes vlink to put that strange program flags in the header.

In any case, i agree that a hello world exe of 400k is not the best solution.

Hi,

I don't have experience with it actually, I just know it's existence, so your criticism is probably valid. I know it's somehow a demoscene-hacker related project, which explains the silly naming... ;) People sometimes indeed get too creative.

Calling an extra tool isn't an issue for FPC as the compiler knows how to invoke various tools per platforms. We don't rely on Makefiles.

BTW, I've seen AROS solve the same problem (need to call another tool after LD) by providing a really thin LD frontend, which just passed all arguments to LD in the background, then calling the extra tool if the linking succeeded. (In fact I think the postprocessing tool is the LD frontend itself, I think.) Then no Makefiles need to be modified, and postprocessing the linker output still works. So there's that solution.

For fpc that would mean however you have to tell it somehow that it can use elf features like sections, even when using gas. I will give it a try at the weekend, i think fpc can be tricked by using -Avasm, but then replacing the symlinks to the assembler.

Changing these kind of things are one-or-two line changes inside FPC actually. You're just facing how the defaults are wired.

The vasm assembler output is indeed quite compatible with GAS, inside FPC vasm support is actually just a thin layer over the GNU assembler writer (again, changing some defaults mostly), and we use vasm's "GNU as compatibility mode" (-gas argument).

I'm sure this used to work, by naming the asm executable just "vasm.prg" and the linker "vlink.prg". Or something. It was too long ago. I think I'll just test under Hatari later today, and see what happens. I'm sure it would just need some minor fixes, if anything.

Cheers,

Thorsten Otto via fpc-devel schrieb am
Di., 25. Jan. 2022, 14:45:

The compiler can call additional tools without problems. It does so for example for MSX-DOS to convert the generated binary into the correct format.

Once you've tested that it works the way to go is to add an additional assembler for Atari that has the features enabled or to add an option to enable the features for the default one.

Regards,
Sven

CET Thorsten Otto wrote

And of course i have to find out what causes vlink to put that strange program flags in the header.

I think i found the reason for that. The offending lines in vlink/main.c are:

            if (!strcmp(&argv[i][5],"flags")) {
              long fl;
              sscanf(get_arg(argc,argv,&i),"%li",&fl);
              gv->tosflags = fl;
            }

(at this point the option argument has already been checked to start with - tos-). fpc passes the arguments "-tos-flags fastload,fastram". So what happens is that sscanf does not find a valid number, does not write any value to "fl", and a (more or less) random value is used as gv->tosflags.

So the documentation in vlink is a bit misleading. It either supports "-tos- flags <number>, or alternatively -tos-fastalloc, -tos-fastram etc., but not the syntax fpc uses. That should be changed to "-tos-flags 7" instead.

gnu-ld has a similar switch, but it already uses 7 as default, so there is need to change that too.

vlink should imho also be changed to check that a valid number was passed, but that's another issue ;)

Hi,

Whoops. Good catch. I agree this is a bug in vlink, so I think I'll report this to Frank Wille. At least the fact that it should error on invalid argument. And of course FPC should pass the right thing.

So the documentation in vlink is a bit misleading. It either supports "-tos-flags <number>, or alternatively -tos-fastalloc, -tos-fastram etc., but not the syntax fpc uses. That should be changed to "-tos-flags 7" instead.

Indeed, I misunderstood the documentation back then. This actually explains some weird random things I've been experiencing with the TOS version all along, so thanks a lot!

gnu-ld has a similar switch, but it already uses 7 as default, so there is need to change that too. vlink should imho also be changed to check that a valid number was passed, but that's another issue ;)

So at least in FPC I fixed this in b3cbf07. Free Pascal (main branch) now passes "-tos-flags 7" to vlink, and also allows to override that 7 value using the newly introduced platform specific -WF parameter.

Further details I've posted to the Atari Forum topic.

Cheers,

Now that vasm is the default, how do i switch back to gas (i still want to try to figure out what's wrong when using gas/ld)?

I tried -Agas, but then the compiler complains about an illegal parameter (so at least the help message seems to be wrong).

Then i tried -Aas, but then the compiler also complains:

Warning: (treated as error) Assembler output selected "AS" is not compatible with "Atari ST/STE"
Warning: (treated as error) "VASM" assembler use forced constexp.pas(87,1) Fatal: There were 2 errors compiling module, stopping Fatal: Compilation aborted

BTW, i think at least 3 of the commits in my PR on gitlab are now obsolete (but gitlab currently seems to have some problem, trying to view them does not display anything and causing it to search endlessly)

CET Thorsten Otto wrote

i still want to try to figure out what's wrong when using gas/ld)

I get the the feeling that there must be something else going wrong:

- when i run the binary compiled by using vasm/vlink in mint, it works
- when i run the binary compiled by using gas/ld in mint, it immediately crashes with a bus-error.
- Running the same binaries in SingleTOS, they both give me "Internal error 2004121202'. Then they both crash with a bus-error, too.

The error number comes from def_system_macro, when it is invoked with an empty name. The crash seems to happen in system.o, during initalization. The external name of the procedure is 'SYSTEM_$
$_RECORDRTTI$POINTER$POINTER$TRTTIPROC'
(where does that come from?) system.o is rather large (~150k of code), although the source is quite small, so that seems to be some inlined code?

 The size of the System.pp is only a small part, cause most of the content of the System unit comes from include files located in rtl/atari, rtl/inc and rtl/m68k (including the function you mentioned which is System.RecordRtti located in rtl/inc/rtti.inc)

Regards,
Sven

Hi,

Umm, almost like I picked vasm/vlink for Atari for a reason. :P But tongue-in-cheek jokes aside, a fixed GAS/LD support would be nice, of course.

- Running the same binaries in SingleTOS, they both give me "Internal error 2004121202'. Then they both crash with a bus-error, too.

That's just probably a symptom of something else going wrong.

The error number comes from def_system_macro, when it is invoked with an empty name. The crash seems to happen in system.o, during initalization. The external name of the procedure is 'SYSTEM_$$_RECORDRTTI$POINTER$POINTER$TRTTIPROC'

It's the mangled name of a function, of course, Sven already told in his e-mail which one. The problem is most likely not in that function though. I've seen similar issues before. These RTTI problems usually come from the assembler or the linker not respecting alignment requirements to some compiler-generated RTTI tables, while compiling or linking the object. (Either ignoring word/longword alignment requirements, or doing word/dword padding despite being instructed otherwise.)

You don't need the whole compiler binary either to reproduce this issue, it's enough to compile anything which uses the sysutils and/or classes units, that will go through the same RTTI initialization, and fail.

Charlie

CET Karoly Balogh wrote

a fixed GAS/LD support would be nice, of course.

Yes, but currently i'm a bit lost here. Since that combination currently does not support "smart linking", i guess i'll stick to vasm for now. There are other parts that should be improved, and seem more important to me (like ARGV support, completing the GEMDOS/BIOS/XBIOS interface etc)

Currently i'm trying to figure out whats wrong with readln() (used eg. when getting the help screen). On both TOS anfd MiNT, i have to press "return" three times. But can't find where readln(textfile) (without any extra arguments) is implemented. All i can find is some declaration in inc/ system.fpd, and the procedure fpc_readln_end in inc/text.inc. Is that actually the function which is called? And how does that magic work? I expect there some problem with expecting CR/LF also when reading from console (although the win32 platform does not seem to suffer from this)

Read(Ln) and Write(Ln) are compiler intrinsics as such you won't find them as-is in the sources. To find out what code is generated for it it's best to check the generated assembly code. In case of ReadLn it's indeed fpc_readln_end that does the main job.

Regards,
Sven

Hi,

Just for the record, the GNU as/ld is Atari specific, it's not a general issue for FPC on m68k. We run just fine with GNU as/ld on Linux/m68k for example, with all the bells & whistles enabled, but of course that's just ELF, and doesn't need any special treatment.

There are other parts that should be improved, and seem more important to me (like ARGV support, completing the GEMDOS/BIOS/XBIOS interface etc)

Totally agree here.

All read/write I/O functions of the RTL just wrap to OS specific calls, implemented in rtl/atari/sysfile.inc. Specifically, you want to look at do_read() and do_write(). These just call gemdos_fread() and gemdos_fwrite() for now, respectively. I think this is the main issue, as I've seen GEMDOS has special calls for console I/O which are not being utilized now. Or maybe you can set some file handle behavior, but we don't do that either.

I expect there some problem with expecting CR/LF also when reading from console (although the win32 platform does not seem to suffer from this)

Again, this isn't a generic problem, but Atari specific. I think the problem is the special nature of the console window, at least there seem to be special GEMDOS specific calls for console I/O. This of course add some complexity, because I didn't know how to choose the right file I/O function based on maybe the type of my file handle, or had no idea how redirection worked, etc. So I just wired it to gemdos_fread(), because that was kinda working (minus the 3 times enter thing). It certaily works for file I/O, otherwise the compiler would be read anything properly, and since even the compiler works, that can't be broken there.

I think gemdos_fread() to a con handle actually just blocks there in case we try to read from stdin, and stdin is a console handle. FPC certainly doesn't try to wait for enter 3 times.

Cheers,

Hi,

Just one more note here, for the ARGV support, general env-var support and fixing the tripple-enter problem, and similar issues, almost everything you need is in rtl/atari already. The framework is there, just a bunch of functions aren't implemented, or aren't implemented fully. I know the rtl/inc (and rtl/objpas) looks huge and intimidating, but 99% of the system specific stuff just falls through there, and eventually calls a function in one of the rtl/atari/sys*.inc files, system.pp or sysutils.pp. So that's where you probably want to look at.

Additionally, for extending the OS interfaces, you probably also want to look into packages/tosunits. In fact you probably want to do that there, because I wanted to keep the gemdos/xbios/etc includes in rtl/atari minimal, and add just what's needed for the RTL itself. This way, those includes kinda document what's _actually_ needed to run the core RTL. The rest (advanced RTL parts, FCL, etc) can use tosunits from packages.

Sorry if this was trivial, but maybe it helps finding the way through the maze that is the RTL code.

Cheers,

CET Karoly Balogh wrote

. I think this is the main issue, as I've seen GEMDOS has special calls for console I/O which are not being utilized now.

Yes, but when using standard handles 0 and 1, Fread() should work the same. There should be no need to call the specialized functions there, but handling of reading from console may need some work.

Again, this isn't a generic problem, but Atari specific.

Yes, but theoretically, win32 should have the same problem. As far as i've seen, ReadFile() is used there. but fpc_readln_end() tries to read until it encounters a LF, and pressing return only gives a CR, not a CR/LF sequence.

CET Karoly Balogh wrote

Additionally, for extending the OS interfaces, you probably also want to look into packages/tosunits.

Yes, thanks, i've seen that already. I has a few more functions than in rtl/ atari/, but still some functions missings. Especially most (if not all) of the MiNT functions.

Hi,

Yes, but changing this is not trivial in platform independent code, because it would also affect text files reading from the disk, where clearly CRLF is used.

Maybe Sven or someone can say more about the Windows analogy, I'm not familiar there. Also then I don't understand why it still works and returns after pressing it 3 times.

Charlie

CET Karoly Balogh wrote

Yes, but changing this is not trivial in platform independent code,

It doesn't have to, if it can be fixed in fpc_readln_end().

Maybe Sven or someone can say more about the Windows analogy, I'm not familiar there.

Thats something i have to check. Normally win32 should suffer from the same problem. The C-runtime (MSVCRT) whould handle that, but not the Windows ReadFile() function. Maybe that is some magic in the console mode of windows.

Also then I don't understand why it still works and returns after pressing it 3 times

I don't understand that either ;)

This isn't something specific to Atari and Win32, CRLF is equally used for several other targets (starting with the first one implemented in FPC, which is 32-bit DOS with extender, continuing with the second one, OS/2, and several other). The implementation in the previously mentioned include file shared for all FPC targets allows any of CR, LF or CRLF as end of line. You can see that at the end of fpc_readln_end():

    if (prev=#13) then
      { is there also a #10 after it? }
      begin
        if (TextRec(f).BufPtr^[TextRec(f).BufPos]=#10) then
          { yes, skip that one as well }
          inc(TextRec(f).BufPos);
        exit;
      end;

If there's #13 (CR), the implementation just checks whether #10 follows (if so, it skips this character), but it stops reading regardless from the result. Again, there's nothing wrong to be "fixed" here.

I know absolutely nothing about Atari, but if I should guess, I'd suggest having a look at how does the function gemdos_fread behave in case of console input - does it return individual characters, or does it return the whole line at once (the latter being the case for other FPC targets as far as I know)? Maybe this is something that needs to be handled specifically when reading from devices (i.e. the console in case of Atari) in the implementation of do_read in rtl/atari/sysfile.inc? I don't know whether there's a reasonable debugging possilibity for Atari, but even if there isn't, you can simply compile a program calling gemdos_fread directly for the stdInput handle and check the exact behaviour this way.

Tomas

CET Tomas Hajny wrote

does it return individual characters, or does it return the whole line at once (the latter being the case for other FPC targets as far as I know)?

Just tried with a small test program, and the behaviour is a bit strange. Fread(0, count, buf) returns when you either press return, or the count has been reached. However, if you press return, the return value does not include the CR, nor is that CR written to the buffer.

[code]
int main(void)
{
	char buf[10];
	long count;
	long i;
	count = Fread(0, sizeof(buf), buf);
	printf("count: %ld\n", count);
	for (i = 0; i < count; i++)
		printf("%02x ", (unsigned char)buf[i]);
	printf("\nPress key\n");
	Cnecin();
	return 0;
}
[/code]

The Window ReadFile function behaves totally differently there. It only returns when you press enter, and the buffer and count includes a CR/LF.

[code]
int main(void)
{
	long res;
	long i;
	char buf[10];
	DWORD outcount;
	res = ReadFile(GetStdHandle(STD_INPUT_HANDLE), buf, sizeof(buf),
&outcount, NULL);
	printf("res: %ld, count: %ld\n", res, (long)outcount);
	for (i = 0; i < outcount; i++)
		printf("%02x ", (unsigned char)buf[i]);
	return 0;
}
[/code]

Bump ;)

Any solution to this? Currently seems to be impossible to use gas at all.

Le 01/02/2022 à 06:28, Thorsten Otto via fpc-devel a écrit :

look at compiler/m68k/ag68kgas.pas unit.

   You will see that atari is listed there:
 grep -inC7 atari ag68kgas.pas
370-
371-       as_m68k_as_aout_info : tasminfo =
372-          (
373-            id     : as_m68k_as_aout;
374-            idtxt  : 'AS-AOUT';
375-            asmbin : 'as';
376-            asmcmd : '$ARCH -o $OBJ $EXTRAOPT $ASM';
377:            supported_targets : [system_m68k_Amiga,system_m68k_Atari];
378-            flags : [af_needar];
379-            labelprefix : '.L';
380-            labelmaxlen : -1;
381-            comment : '# ';
382-            dollarsign: '$';
383-          );

The idtxt field is the string you need to use to enable GNU assembler for aout format, thus you should use
-Aas-out
compiler option. It is true that this entry is missing in ppc68k -h
output...

Pierre

Pierre

CET Pierre Muller wrote

thus you should use -Aas-out compiler option.

Ah thx. Would make more sense to just use "as" like for other targets, but i see that this target is also used for amiga.

Right, I expected something like that based on the described behaviour. Is the pressed CR never returned then, or is it returned in a following fread call?

The Window ReadFile function behaves totally differently there. It only returns when you press enter, and the buffer and count includes a CR/LF.

Indeed, that's what I already mentioned. Moreover, the ReadFile function on Windows (and similarly the respective equivalents on various other platforms) doesn't even allow the user to enter more characters than the buffer length _minus_space_for_the_terminating_end_of_line_marker_ when reading from console (not necessarily when reading from standard input - if the standard input is redirected and gets input from a file, more characters are accepted). In other words, reading characters (pressed keys) stops when reaching character 253 and nothing except the Enter key is accepted (and the Enter key is then stored as #13 and #10 to the end of the buffer as correctly mentioned by you). I'm afraid that the observed behaviour of fread suggests that you need to modify the do_read implementation for atari to do the same if reading from console - in other words, you need to call fread with one less character in "len" in that case (and add it to the end of the buffer being returned from do_read afterwards).

BTW, be careful about distinction between the standard input handle and input from console unless either no redirection of input is possible, or the handle of such an input changes to a different value in that case (as of now, the implementation of do_isdevice for atari works only with the handle number rather than checking what the handle refers to using some special API function, but that may not be correct).

Tomas

Hi,

The distinction is made for a reason, namely to support GNU as both with and without section smartlinking. If you want to work on "modern" GNU as support, just add system_m68k_atari into ag68kgas.pas, line 363. Then both -Aas-out and -Aas would work, the later producing assembler source with many sections for section smartlinking.

Back then this wasn't a thing on Amiga, or Atari, therefore they haven't been added to the assembler list that enables section smartlinking. Also note there might be small things to tweak here-and-there in the writer to make this work, but if you want to enable it as a developer, while keeping the existing a.out support intact, this is the way.

Charlie

CET Thorsten Otto wrote

- Running the same binaries in SingleTOS, they both give me "Internal error 2004121202'. Then they both crash with a bus-error, too.

That internal error is currently striking back. This happens both with my own compiled binary, and the one from the nightly build, but only in SingleTOS. When i run them under MiNT, they both work. Also, that bus-error at the end only happens in SingleTOS, too.

I'm quite sure that a few days ago (when i tried to find out the problem with reading form console) at least my own binary worked. Could that be some more or less random heap corruption?

Hi,

Could be. Does it also happen, when you compile everything for the 68020? (-Cp68020)

Otherwise to me it sounds more like something related to the executable layout, especially if a similar problem also occurs with simpler examples. I saw you added a default linker script for the aoutmint format, I haven't checked it in detail, but for example vlink won't align the start sections by default, unless you explicitly tell it to do so in the linker script, I think. (At least it doesn't do that for raw binary output for example.) And if that happens, who knows what the OS exe loader makes of that later on. Going to guess that MiNT and SingleTOS uses a different loader?

Charlie

CET Karoly Balogh wrote

Does it also happen, when you compile everything for the 68020? (-Cp68020)

Nice, that's it. Compiling everything for 68020, and it works. Thats strange. But that also explains why it worked a few days ago, because the default has changed only recently.

if a similar problem also occurs with simpler examples.

The printenv test runs normally, only crashes at the end (when i remove the pterm0). The simple hello works without problems, i think it does not use any strings at all.

I saw you added a default linker script for the aoutmint format

Yes, that is required if you want to produce mintaout format. Because vlink is invoked with a linker script, it does not use its own default. The one that i added is the same as used by vlink.

who knows what the OS exe loader makes of that later on. Going to guess that MiNT and SingleTOS uses a different loader?

For the OS, there is no difference. Both formats can be run both on TOS and MiNT.

CET Thorsten Otto wrote

because the default has changed only recently.

That reminds me of another problem: if i'm not wrong, the compiler does not use different sets of libraries depending on whether your are compiling for 68020 or not. That means, if you use -Cp68020, your code will be compiled for 68020, but will link to the system libraries that were compiled for 68000.

So in the short term, would it be possible to provide two (or maybe three, one with FPU) different snapshot builds, like is done for the amiga?

In the long term, it would be nice to have some automatic selection of the correct libraries. Otherwise it will not be possible to produce 68k binaries with a compiler that was compiled for 68020, since that will still pull in 68020 code from the libraries.

CET Thorsten Otto wrote

Nice, that's it. Compiling everything for 68020, and it works.

Hm, or maybe not. A few hours later, installing a freshly compiled version, i get that internal error again. Damn. Must be some other kind of randomness involved.

Hi,

Is the compiler binary itself a 68020 or a 68000 binary? The point being, although the 68000 support should be "good enough", it's still possible that there's a miscompile in there, because it's less tested than the 68020 counterpart. If the compiler binary is 68020, that's "good news" in the semse that it's probably only an Atari-specific bug, which means it's 99.999% something in the RTL.

On a related note, maybe we should think about setting up a 68000 testsuite run somehow, because so far we only test on 68020 (and under Linux and QEMU), I think.

Charlie

CET Karoly Balogh wrote

Is the compiler binary itself a 68020 or a 68000 binary?

All i changed was using

make zipinstall OS_TARGET=atari CPU_TARGET=m68k 'CROSSOPT=-Cp68020 '

so i think that should be a 68020 binary?

Thorsten Otto via fpc-devel schrieb am
Mo., 7. Feb. 2022, 13:00:

A FPC compiled for 68020 can generate 68000 code just fine and the other way round (assuming of course that it was compiled without bugs ;) ). It's just that you need to provide it with the correctly compiled units. You can supply those in the fpc.cfg and with $fpcsubarch you can get the name of the currently selected processor to use in a path name (the MS-DOS target makes use of this for example).

Regards,
Sven

CET Sven Barth wrote

It's just that you need to provide it with the correctly compiled units

Yes, i see. But that requires some manual fiddling with the library directories, and you need both 68000 and 68020 versions somehow.

How do the Amiga folks solve that? Or don't they care about 68000 anymore?

Hi,

We do care, although FPC existed and focused on 68020+ first, and the vast majority of application development on Amiga happens for 68020+. We didn't really integrate the "legacy" support in the current 3.2.2 release cycle, but we have to in the next one.

An additional problem on Atari is that at least for TOS it uses 8.3 filenames, so it's difficult to do subarch directories, which is not a problem on Amiga. Not under mind, but going with this would probably mean giving up TOS support.

There's also the FPU version, which is yet another additional set of libraries and units, and if we include all of this, the compiler archive quickly grows too large to even process on real hardware in a practical way. For my own cross-suite I just keep all builds separate anyway, and don't use any global settings.

Charlie

Hi,

Karoly Balogh wrote

Not under mind, but going with this would probably mean giving up TOS support.

*Not under MINT, I mean, sorry for the typo.

Charlie

CET Karoly Balogh wrote

but going with this would probably mean giving up TOS support.

Yes, that 8.3 restriction might be the worst that was ever made. But even unices of that time allowed only 14 character long filenames.

I think you should not care about that restriction. There are ways to get around that (using mint, magic, vfat partitions, emulators...). And for the units, its not a problem in most cases (i guess all that fcl-* stuff will never get ported to Atari).

Hi,

Thorsten Otto wrote

> but going with this would probably mean giving up TOS support. Yes, that 8.3 restriction might be the worst that was ever made. But even unices of that time allowed only 14 character long filenames.

It is also the main reason why I personally only thought about Atari as a cross-only target, and not something I really want to run the compiler on, apart from "proof of concept".

I think you should not care about that restriction. There are ways to get around that (using mint, magic, vfat partitions, emulators...).

But this re-raises the idea of doing a separate MINT target... ;) Which could happily use long file names, and the original "legacy" TOS could stay 8.3. But well, I'm no Atari expert.

And for the units, its not a problem in most cases (i guess all that fcl-* stuff will never get ported to Atari).

A lot of the FCL stuff is platform independent, so most of it either already compiles, or should compile as soon as some thin or simple platform dependent layer gets implemented. This isn't always the case, but most of it works on Amiga-likes, and it wasn't the hardest thing to get working.

Charlie

I'm currently trying to set this up and have a problem with the cross- compiler. Although that was configured for atari and 68000, it still has LINUX and CPU68020 defined while processing the config file. My config file has - Tatari set, so the LINUX define is no issue. But if i invoke the compiler without excplicit -Cp<x>, it will generate code for 68000, but take the libraries from the 68020 directory. It works as intended if i explictly specify -Cp68000.

Why are those macros still defined?

I also noticed that the cross-compiler still tries to locate units in /usr/ lib/fpc/3.3.1/units/atari/rtl
That does not cause problems (because the directory does not exists), but doesn't look quite right.

Hi,

Thorsten Otto wrote

I'm currently trying to set this up and have a problem with the cross-compiler. Although that was configured for atari and 68000, it still has LINUX and CPU68020 defined while processing the config file.

That probably can't be helped, because LINUX and 68020 is always the default for the m68k crosscompiler. The crosscompiler for the given CPU target will be the same, regardless of the OS target. So technically it is possible to release a 68k crosscompiler package that could target both Atari and Amiga (sic!), because the only difference is the units. :)

My config file has -Tatari set, so the LINUX define is no issue. But if i invoke the compiler without excplicit -Cp<x>, it will generate code for 68000, but take the libraries from the 68020 directory. It works as intended if i explictly specify -Cp68000.

Yes, and I agree this is a valid issue, because apparently it only sets the target CPU subarch and target FPU settings after the entire config file was processed. We probably have to set these when the -T argument is first encountered.

Why are those macros still defined?

See above.

I also noticed that the cross-compiler still tries to locate units in /usr/lib/fpc/3.3.1/units/atari/rtl That does not cause problems (because the directory does not exists), but doesn't look quite right.

It seems this global path is hardwired on Unix systems, as the default unit path. You can overwrite this with the FPCDIR environment variable. See the relevant code here:

https://gitlab.com/freepascal.org/fpc/source/-/blob/main/compiler/options.pas#L4643

I'm not claiming I like this solution, but I guess the issue is mostly harmless.

Charlie

Note that this should work if the target is passed on the command line because the command line is parsed twice to avoid exactly this. If you need to set the target in the config, just set the target cpu and target fpu (-Cp and -Cf) as well. As the workings of the switches is interwinded there is unfortunatly no good other solution.

Hi,

I'm thinking about refactoring this.

Couldn't we include the default CPU/FPU subatch in target_info? That would simplify away a bunch of platforms, which is now dealt with in a huge case-switch.

Alternatively, we could add a "reevaluate CPUs" function and move the switch there, and call it whenever the target OS and the ABI is set, which is really the two only cases where target CPUs have to be set, as far as I can see from the code.

Charlie

I think it must be tried, in practice one hits also some strange obstacle one never things before ... I would also expect that the former works and is the better solution though it requires also that the CPU/FPU/ABI are immediately set.

CET Florian Klämpfl wrote

I think it must be tried, in practice one hits also some strange obstacle one never things before ... I would also expect that the former works and is the better solution though it requires also that the CPU/FPU/ABI are immediately set.

There is another strange behaviour: if i invoke the compiler with -CpCFV4E, the macro CPUCFV4E is set while processing the config file, but not CPUCOLDFIRE. That one is only set while compiling the source file.

Maybe, when the code is refactored, that will also be solved?