PDOS for Amiga

[kerravon]

Originally Posted by kerravon

I believe there is another library available that has the entire C library available. So that I can have something similar to mingw (which uses msvcrt.dll on Windows).

I'll try to find what it's called (if it exists) and how to use it.

Ok, apparently before AmigaOS 4.0 there was no standard library, and instead there was libnix, ixemul, Lattice/SAS C, Aztec C, DICE C - all incompatible.


And then somehow newlib.library came along (presumably from whoever owns AmigaOS) and created a standard (and maybe that standard was backported to earlier versions of AmigaOS?).



I'm happy to work to a standard - but I want to have a mini-clone of that. The clone will be strictly C90.



Apparently there is also a clib2/clib4 that is presumably a moving target, and has a different goal (POSIX) to what I am interested in (C90 - and yes, I'm aware that POSIX is a superset of C90 - I'm not interested in the superset at all).


Can anyone briefly describe how newlib works? ie I am familiar with the registers on entry to an Amiga program (d0 and a0) and I know how to start at address 4 in memory and scan for libraries. But once I find newlib.library I do ... what? I assume there is a large structure containing every C90 function, plus some POSIX functions, and I just call whichever one I want.


(that's what I do in PDOS-generic too, except the structure pointer is given as a stack parameter).


Thanks. Paul.

[kerravon]

Originally Posted by kerravon

Ok, apparently before AmigaOS 4.0 there was no standard library, and instead there was libnix, ixemul, Lattice/SAS C, Aztec C, DICE C - all incompatible.

Actually - I might clone them all (to the C90 subset).


Unless I'm missing something, it's just a little bit of "glue" code required whenever someone comes up with a new version. Unless the function calling convention (registers/stack) changes. I need consistency there. At least for functions with a variable number of parameters - like printf.


Then you should be able to pull out your old SAS/C compiler, build a small executable that does hello world or whatever, and then run it on my 68000 ELF executable under 68000 Linux/BSD or qemu-m68k wherever that runs.


You won't be able to run the SAS/C compiler itself under my clone though, as it likely uses non-C90 functions.

[Thomas Richter]

Originally Posted by kerravon

Ok, apparently before AmigaOS 4.0 there was no standard library, and instead there was libnix, ixemul, Lattice/SAS C, Aztec C, DICE C - all incompatible.

Err... what? They are all compatible in the way that they provide the ANSI C interface and map them to the Amiga system interface. There is certainly no "standard" because there is not a single compiler standard either. Depending on the compiler configuration, arguments are either passed on the stack or in registers, or ints are 32 or 16 bit long, or the data segment is addressed through a register or absolute.... It does not make sense to make that a "system library" because the solution actually depends - by definition - on the compiler and its configuration. If you want to program the Amiga on the system level, the ANSI-C interface is the wrong interface in first place. Amiga has a system level that descends from Tripos, not from Unix, and what you expect the system interface is in the dos.library and the exec.library.

Originally Posted by kerravon

Can anyone briefly describe how newlib works?

You ignore it? Again, what type of problem do you want to solve? A C interface wrapper? Use that of your compiler because it depends on your compiler, and the configuration of your compiler. Or do you want to program in Amiga-C and not ANSI-C? Then use the functions of the dos.library. You find there functions like Open(), Close(), Write() or FPrintf() that are all close cousins of the ANSI C system functions, but not exactly. What the compiler link libraries do is to provide an exact mapping, including mapping Amiga file handles to "int" file descriptors or "FILE *", but why bother with this indirection, unless you want to port an ANSI-C program - and if you want to do that, the compiler has a link library for it.

[kerravon]

Originally Posted by Thomas Richter

Err... what? They are all compatible in the way that they provide the ANSI C interface and map them to the Amiga system interface. There is certainly no "standard" because there is not a single compiler standard either. Depending on the compiler configuration, arguments are either passed on the stack or in registers, or ints are 32 or 16 bit long, or the data segment is addressed through a register or absolute

Ok, thanks.

Use that of your compiler because it depends on your compiler, and the configuration of your compiler. Or do you want to program in Amiga-C and not ANSI-C? Then use the functions of the dos.library. You find there functions like Open(), Close(), Write() or FPrintf() that are all close cousins of the ANSI C system functions, but not exactly.

I already use Write() etc. Which means all my application executables have the library statically linked and are larger because of that.

What the compiler link libraries do is to provide an exact mapping, including mapping Amiga file handles to "int" file descriptors or "FILE *", but why bother with this indirection, unless you want to port an ANSI-C program - and if you want to do that, the compiler has a link library for it.

I have my own compiler (a variant of gcc 3.2.3) and I have my own C library (pdpclib). Currently the only option is to use that compiler, statically link the C library, and then you have an Amiga Hunk.


So the calling convention will be dictated by the existing standard gcc 3.2.3 as I haven't changed the calling convention.


But if there is an existing library (in the linked list) that uses the same calling convention as gcc 3.2.3, then I can clone that (all of the ones that use that convention, most likely).


And some news - pdld has been updated to take hunk object and produce ELF output - but not relocations yet. That may or may not be good enough for qemu-m68k to work - will test in due course.



Source is around here:


https://sourceforge.net/p/pdos/gitco...dld/src/hunk.c

[Thomas Richter]

Originally Posted by kerravon

I already use Write() etc. Which means all my application executables have the library statically linked and are larger because of that.

That is a contradiction. If you use Write() instead of write(), then you do not need a compiler library (or if so, only a very small one containing stub functions). Same if you use Printf() instead of printf(). The "captial-letter functions" are in the dos.library and do not require a compiler link library, but are not "quite ANSI-C". For example, Printf() assumes by default 16 bit ints and has no floating point support. printf() assumes whatever integer type the compiler chooses, and supports floating point of the format the compiler is configured to use.

Originally Posted by kerravon

But if there is an existing library (in the linked list) that uses the same calling convention as gcc 3.2.3, then I can clone that (all of the ones that use that convention, most likely).

Amiga "dynamic" libraries always use the calling convention of the Amiga, and that is "place values in registers". That means that if you use a "dynamic library" in the amiga format, you would need to tell your compiler that it either calls this library with the right conventions (usually through a file full of pragmas) or use another library full of stub functions, whatever your compiler supports. For gcc, this is usually a header file defining inline functions that call the dynamic library.


Amiga link libraries use whatever convention was used when the library was compiled, so it has to match the compiler configuration.

[phx]

Originally Posted by kerravon

Then you should be able to pull out your old SAS/C compiler, build a small executable that does hello world or whatever, and then run it on my 68000 ELF executable under 68000 Linux/BSD or qemu-m68k wherever that runs.

No. It's not so easy. Even simple AmigaOS executables with stdio-like input and output will use at least exec.library and dos.library (also refer to Thomas' reply).

So you would have to emulate their functions, which requires a lot more than "glue" code to some clib routines. You would probably end with something like "vamos" (virtual AmigaOS runtime): https://github.com/cnvogelg/amitools.../docs/vamos.md

[kerravon]

Originally Posted by Thomas Richter

That is a contradiction. If you use Write() instead of write(), then you do not need a compiler library

My C library (PDPCLIB) uses Write(). For the benefit of applications, which use neither Write() (Amiga) nor write() (Posix) but instead fwrite (C90).


I do not give applications the ability to call either Write() or write(). They get C90. Nothing more, nothing less.

Amiga "dynamic" libraries always use the calling convention of the Amiga, and that is "place values in registers".

Oh. Is there something preventing me from having a library matching gcc's native convention? I just checked - and it puts parameters on the stack, and caller fixes the stack - ie standard cdecl.


Do none of the libraries - ix, SAS/C - use the cdecl convention in their dynamic libraries?

That means that if you use a "dynamic library" in the amiga format, you would need to tell your compiler that it either calls this library with the right conventions (usually through a file full of pragmas) or use another library full of stub functions, whatever your compiler supports. For gcc, this is usually a header file defining inline functions that call the dynamic library.

Ok, I would use some Motorola syntax assembler stubs if I was doing that, to allow reuse by compilers other than gcc, e.g. SubC. However, I'm not sure that is technically possible for something like printf with variable parameters.


Also, I have now had a chance to test the pdld output - it is generating LSB headers instead of MSB, which my loader (which the author tested against) is willing to accept, but qemu-m68k isn't, so I am waiting for him to update it to generate MSB.

[Thomas Richter]

Originally Posted by kerravon

Oh. Is there something preventing me from having a library matching gcc's native convention? I just checked - and it puts parameters on the stack, and caller fixes the stack - ie standard cdecl.

The standard ABI for Amiga shared libraries, for example. Amiga ABI means parameters in registers. Stack-based argument parsing is nothing the ABI of Amiga shared libraries would cover and would be representable as ".fd" or ".sfd" file. Having the callee to clean up the stack is even more unconventional (though some compilers did it). Typically, the stack is cleaned up caller side, which has the advantage that some cleanup can be delayed.

Originally Posted by kerravon

Do none of the libraries - ix, SAS/C - use the cdecl convention in their dynamic libraries?

SAS/C does not use dynamic libraries for the C/Posix functions. Actually, none of the compilers I am aware of do. That's all part of a classical link library (sc.lib, scnb.lib for the SAS/C) that you need to pick according to the configuration of the compiler. It would also be a bit unusual since what the compiler needs for a FILE type is really compiler and library specific, and it is also typically also managed through the compiler specific memory heap (aka malloc()). This datatype is not defined in AmigaOs and compiler specific (the closest we have is a BPTR to FileHandle structure). What the compiler libraries do is to provide a minimal C89 and POSIX layer for compatibilty with C. A native Amiga-C program would simply not use that - which is also the reason why the command line tools in C: are so tiny; they do not use Posix functions but call the system library functions, despite being implemented in C.

Originally Posted by kerravon

Ok, I would use some Motorola syntax assembler stubs if I was doing that, to allow reuse by compilers other than gcc, e.g. SubC. However, I'm not sure that is technically possible for something like printf with variable parameters.

Varadic functions on Amiga typically pass a pointer to a stack frame in a register - or to put it differently, the dos.library implements something like VPrintf(), and the compiler does the rest of the magic to provide you Printf() from that function (which is not really complicated). Look up the include file for pramgas/dos.h to find out how the gcc handles this, there is surely something.

[kerravon]

Originally Posted by Thomas Richter

The standard ABI for Amiga shared libraries, for example. Amiga ABI means parameters in registers. Stack-based argument parsing is nothing the ABI of Amiga shared libraries would cover

These "Amiga shared libraries" - is there any barrier to 3rd parties adding them?


I guess I am more interested in letting gcc set the ABI.


There are compromises when using msvcrt.dll too - e.g. it isn't actually documented.

It would also be a bit unusual since what the compiler needs for a FILE type is really compiler and library specific,

The same thing happened with msvcrt. In the case of pdpclib, a girl from Slovakia (Alica) - not the pdld author who is also from Slovkia - developed a technique to cope with that.

and it is also typically also managed through the compiler specific memory heap (aka malloc()).

Is that a problem? The shared library is given a pointer to the FILE structure. That's how it works with msvcrt.dll.

This datatype is not defined in AmigaOs and compiler specific (the closest we have is a BPTR to FileHandle structure). What the compiler libraries do is to provide a minimal C89 and POSIX layer for compatibilty with C. A native Amiga-C program would simply not use that - which is also the reason why the command line tools in C: are so tiny; they do not use Posix functions but call the system library functions, despite being implemented in C.

msvcrt-based programs are also small.



Ok, so based on what you have told me, it seems that what I want doesn't already exist on the 68000, so I will create my own msvcrt.library - unless there is a barrier to installing it.


BFN. Paul.

[kerravon]

Originally Posted by kerravon

I guess I am more interested in letting gcc set the ABI.

Just to be clear - obviously gcc can't set the ABI of dos.library. So msvcrt.library will have assembler stubs to allow it to call Write() in dos.library - stubs that already exist.

[malko]

Originally Posted by kerravon

[...] Ok, so based on what you have told me, it seems that what I want doesn't already exist on the 68000, so I will create my own msvcrt.library - unless there is a barrier to installing it [...]

Considering the meaning of the acronym "msvcrt" (Microsoft Visual C++ runtime) I hope you will find a better name than that and especially more in adequation with the Amiga.
The power of names in success is not to be underestimated

[kerravon]

Originally Posted by malko

Considering the meaning of the acronym "msvcrt" (Microsoft Visual C++ runtime) I hope you will find a better name than that and especially more in adequation with the Amiga.
The power of names in success is not to be underestimated

I want to reserve pdpcrt.library for 64-bit long, pipping out "Microsoft" for the 68000 and Microsoft for the 80386 and x64.

[malko]

^ "pipping out" looks good

[kerravon]

Originally Posted by malko

^ "pipping out" looks good

I forgot to mention ARM32 and ARM64 too.


I have made the changes required so that PdAndro:


https://play.google.com/store/apps/d...ro&hl=en&gl=US


is now a mini clone of Win32 ARM (Windows 11 for ARM still supports that - but maybe not for long). It's still waiting for the APK to be updated with the new bios.exe.


I'm actually doing the 68k stuff now to take a break from that work which drained me (issues with floating point - still not resolved).


And I'll be doing the same for Win64 ARM.


Also the 68k is basically giving closure to what I wanted to do all along - move from x86 to 68k. I'm still resolving "MSDOS best practices" to ensure that the move could have been made (ie proving that C90 was viable all along).


So the movement to ARM is the modern-day equivalent.

[kerravon]

Originally Posted by phx

No. It's not so easy. Even simple AmigaOS executables with stdio-like input and output will use at least exec.library and dos.library (also refer to Thomas' reply).

So you would have to emulate their functions, which requires a lot more than "glue" code to some clib routines. You would probably end with something like "vamos" (virtual AmigaOS runtime): https://github.com/cnvogelg/amitools.../docs/vamos.md

This made me pause for some time to remember how I managed on msvcrt.dll.


While standard mingw produces executables that use more than just msvcrt.dll, I instead use it (or my replacement) in conjunction with PDPCLIB. And PDPCLIB limits itself to just msvcrt.dll.


So SAS/C would probably need to be the same - compile with SAS/C, link with PDPCLIB (PDPCLIB targeting SAS/C dynamic library - although it sounds like it doesn't exist).


And then you may use the SAS/C dynamic library (if it exists) or you may use my replacement for the SAS/C library (just as PDPCLIB builds into a (mini/subset) replacement for msvcrt.dll).


With regarding exec and dos libraries - I'm not sure what of them will be required - but I will be starting with cloning them anyway, to support my existing statically-linked binaries.

[kerravon]

Originally Posted by kerravon

And then you may use the SAS/C dynamic library (if it exists) or you may use my replacement for the SAS/C library (just as PDPCLIB builds into a (mini/subset) replacement for msvcrt.dll).

It seems like this is what I want to create a mini-clone of:



https://aminet.net/package/util/libs/ixemul-48.0



ie it actually exists. And so is the closest thing to msvcrt.dll


And I will only clone the C90 functions from that. I assume that has the full C90 library in it.

[kerravon]

Originally Posted by kerravon

It seems like this is what I want to create a mini-clone of:
https://aminet.net/package/util/libs/ixemul-48.0

But as noted - I will use a technique so that my FILE structure doesn't need to match theirs.


Which will be fine so long as you link with PDPCLIB (which I will).

[kerravon]

Originally Posted by malko

Considering the meaning of the acronym "msvcrt" (Microsoft Visual C++ runtime) I hope you will find a better name than that and especially more in adequation with the Amiga.
The power of names in success is not to be underestimated

So I expect to be using ixemul.library as the name. And if you don't already have the existing ixemul.library installed, you can install mine instead - but either will work - for the limited goal of running D7-conforming, C90-conforming, ixemul-subset-conforming programs (ie in practice your only choice will be gccami + PDPCLIB to start with).


And if you use my bios.exe mini Amiga clone, you don't actually need a real ixemul.library to exist at all, as it is built-in to the Linux executable, with the C library recursively called (that's how my Win32 clone works already).

[Thomas Richter]

Originally Posted by kerravon

These "Amiga shared libraries" - is there any barrier to 3rd parties adding them?

Not sure what you mean? You can surely add the SAS/C linker libraries to your projects if you own SAS/C. If you don't, then you cannot. Remember that SAS/C is a commercial product. (Or rather "was"). Or is the idea to create a custom link library based on the SAS/C interface and let users link to that for SAS/C built object code and by that redirect C90 stdio to your layer.

[kerravon]

Originally Posted by Thomas Richter

Not sure what you mean? You can surely add the SAS/C linker libraries to your projects if you own SAS/C. If you don't, then you cannot. Remember that SAS/C is a commercial product. (Or rather "was"). Or is the idea to create a custom link library based on the SAS/C interface and let users link to that for SAS/C built object code and by that redirect C90 stdio to your layer.

No, I mean - I have this code:


library = (struct Library *)SysBase->LibList.lh_Head;
while (library != NULL)
{
if (strcmp(library->lib_Node.ln_Name, "dos.library") == 0)
{
DOSBase = library;
break;
}
library = (struct Library *)library->lib_Node.ln_Succ;
}



so now I am expecting a ixemul.library to exist (given that no sasc.library appears to exist), and I don't want it to be the normal ixemul.library - I may wish to start with a clean system (on a genuine Amiga 500 - or 2500 to start, as PDPCLIB currently needs 68020 and FPU until I get more code) and install my own ixemul.library.


ie I assume I don't need to jailbreak my Amiga 500/2500. I assume there is no "signing" required. I assume there is not a limit of the number of shared libraries I am allowed to install. I assume names aren't restricted to ones that Commodore has sanctioned - that sort of thing.



So I am free to plonk in an msvcrt.library or ixemul.library (expecting to use the latter name), and the above while loop will find it if it is installed?