Contact to Metacomco (and Lattice!) because of their C Development Kit? (The Lattice C compiler)

[stephen_usher]

You would not normally use libc in romable programs anyway. Libc is not re-entrant and also relies on global state. This is true no matter the compiler.

It depends upon what you mean by "ROMable". If it's, say, a SuperBASIC extension which is installed in a ROM then I'd say it would be "ROMable". You'd probably only use a system call shim library and not libc, or a simplified libc which could be embedded into the object file.

However, if you want a low-level ROM replacement, then no, not totally as the bootstrap code and a set of "system calls" would have to be written in assembler first and then the C compiled object code called in the correct manner. You'd need a special linker to do this as well.

[Peter]

C68 and its Libraries do not create reentrant, ROMable code, [...]

Of course C68 creates reentrant code - if one knows how to program such code in C.

[ql_freak]

You'd have to ask Fred Toussi, who wrote Text 87 on the Atari. He probably created his own libraries.

Nope, I have had intensive contact with Fred (I wrote my "Diplom-Arbeit" with text87, the output was much better than those of other students who used WordStar, Word, ... for DOS – e.g. proportional fonts with Right Justify and WYSIWYG!), cause I have had written a printer driver for my Star printer (Fred wrote a driver for the same model, and we both have had the same problem, it seems the problem was with the printer). Fred told me, that text87 has been written in C++ (i.e. with a cross compiler). It would be nice if we could get hands on this C++ cross compiler and its libraries.

p.s.: And of course it would be extremely nice, if we could get hands on the source code of text87 itself. It is such a great word processor, one of the best at its time.

[ql_freak]

You would not normally use libc in romable programs anyway. Libc is not re-entrant and also relies on global state. This is true no matter the compiler.

That's not true. At least the "standard lib" (aka Libc [#include <stdio.h>]) from EJC should produce reentrant code. If you want to test it, see the attachement. The program runs quite long, i.e. you could HOT_CHP it and call it multiple times (perhaps use output redirection).

[ql_freak]

C68 and its Libraries do not create reentrant, ROMable code, [...]

Of course C68 creates reentrant code - if one knows how to program such code in C.

C68 has options (as Lattice C) to produce reentrant code. But there is (IMO) not even a startup object file/lib to use it and no libraries. And do you have tested, that the options to produce reentrant code are working correctly! For Lattice C this is proven, because it was used on a lot of systems (not just 68k machines) and there is (THANK YOU ERLING) EJC. Lattice was THE C COMPILER for the microcomputers at its time. To produce reentrant code with Lattice you must use the option (command line switch) -b for phase 1 of the compiler (and eventually -f at phase 2). C68 as delivered (with all its libraries) produces (as the Metacomco C Development Kit with the Lattice compiler) not even position independent code(!). The startup code which must be linked with your object file relocates all absolute addresses so that the code can run at the address at which it will be loaded by QDOS.

Even if the C68 options to produce reentrant code are working, you can write functions, which you can call from assembler. But you cannot even write the "hello world" program from Kernighan & Ritchie, cause this uses printf(), which is in the standard library which is not reentrant.

[Derek_Stewart]

Hi,

The source code to C68 is available, could that be enhanced to produce reentrant code?

[stephen_usher]

Even if the C68 options to produce reentrant code are working, you can write functions, which you can call from assembler. But you cannot even write the "hello world" program from Kernighan & Ritchie, cause this uses printf(), which is in the standard library which is not reentrant.

But you wouldn't want to. If you're wanting to use a reentrant routine it would be in a system location and you would code appropriately, only using system calls and not using any library routines at all. System calls would be atomic and you would only ever use local variables held on the stack. If there were any areas of the code that you'd not want two copies of the code running in parallel then you would protect those with a semaphore system anyway. At least on the QL you don't have to worry about multiple cores, merely multitasking.

[tofro]

Even if the C68 options to produce reentrant code are working, you can write functions, which you can call from assembler. But you cannot even write the "hello world" program from Kernighan & Ritchie, cause this uses printf(), which is in the standard library which is not reentrant.

Well, the first question would be "why would you ever even want to write 'Hello World' in a re-entrant way??".

People are mixing up "re-entrant code", "ROMable", and, especially in the QL scene, "re-entrant programs" (in TT-speak "pure programs") all the time - These are three totally different things, however.

Re-entrant code is perfectly possible with C68 - simply don't use global or static variables (and don't use C library routines that do that) and your code will be perfectly re-entrant. Use mt_create() to run various jobs within a single executable on the very same code, no problems whatsoever.

ROMable programs are programs that never modify themselves and have code and non-const data cleanly separated (in the case of a QDOS job, they only ever write to the job's data space and allocated heap memory). You can only do that in C68 when you tell the compiler to not use its standard relocating loader but rather produce position-independent code. Also, don't use statics or globals, as above. Unfortunately, you cannot use the standard startup code and many/most of the libraries - which you wouldn't want to anyways, because of the nature of code you'd want to blow into a ROM (See above: Why would you want to put "HelloWorld" into a ROM?).

"Pure" programs are programs that can be started through the Hotkey System multiple times and can share the same instance of code, but have a private data space - They have basically the same restrictions as ROMable code.

QDOS/SMSQE is built in a way that it comforts programs of all kinds - Even Device drivers or Things don't necessarily need to be re-entrant, at least not when they serve atomic calls. The OS makes sure there is ever only one code path through them at any on time.

"Impure" programs are in no way any "worse" than "Pure" ones. Just different. There is actually not much point to desire only "pure" programs on the QL - You have to invest a large amount of effort if you aim for them in anything but assembly. And, I'd rather have a working, "impure" one, than a non-finished "pure" one.....

[Peter]

C68 has options (as Lattice C) to produce reentrant code. But there is (IMO) not even a startup object file/lib to use it and no libraries.

No, it does not require specific options or startup. I used reentrant code intensively when working on multitasking-capable internet stuff. Of course the initial relocation must happen, but once done, the same code (if correctly written) can safely be interrupted and called again before its previous execution has completed.