The Sinclair QL Forum

NOTE: This thread started originally on the first 4 pages in the thread (discussion) "EJC (C-Compiler) experiments". But as it is offtopic in this thread, I have created this one.

Peter said in the above thread: "PDQC can create ROMable code".

Well that is correct and (I'm afraid) also wrong. The C-Compiler of PDQC (Lattice as in EJC and Metacomco C Development Kit [MCDK]) can create reentrant and even ROMable code. Therefore you must use the compiler option "-b" in phase 1.

But the PDQC Development System does (I'm afraid) not create reentrant code, not even position independent code. The reason is, that the libraries (at least qlib_l) are NOT compiled with the -b option. There is a (short) manual for PDQC on Dilwyns eBooks page, and it states in the description for option -b:

"It may be possible to link with modules not compiled with this option if they do not use any register pointer variables but the practice is not recommended. Also the supplied QL library qlib_l has not been compiled with this option, as it would require a special linker to use programs with over 64K of data. This option is still useable if you only wish to link to similarly compiled object files or to your own, carefully designed assembly language objectfiles."

This is the same as with the original MCDK. EJC Libraries are compiled with the -b option and so programs created with EJC are reentrant and ROMable (but static data limited to 64 KBytes) AND functions must be arranged in a way, that jumps (branches) to them are never > +- 32KByte. If you have a look in the attached screenshot in my message for the example program simplecalc (in thread EJC (C-Compiler) experiments page 4), you will see the command for phase 1 of the Lattice compiler. The cc (or my changed ecc) compiler driver inserts the -b switch as default.

It would be of interest, if EJC can be used with the Lattice C from PDQC, as it seems to support some newer constructs like const. But it's an Atari ST program which requires the TOS emulator. I don't know what file is the TOS emulator and how it must be started. But it should be possible, albeit the cc compiler driver most probably must be adapted.

Conclusion: It's not sufficient to have a compiler, which can create reentrant code. More important is, that all library functions are reentrant. Of course you can use Lattice C to compile modules (with the -b option) and then call it's functions from reentrant assembler code.

BTW: AFAIK Prospero Fortran and Pascal also create reentrant code (code which can be HOT_CHP'ed without the I(gitit) option). AND, albeit not capable of Multitasking in the beginning (because the Cursor was not enabled, can be cured with a few lines of SuperBASIC), the PSION programs are reentrant.

Hmm. What sort of code does one put into ROM?

• Device drivers (Peter's use case)
• S*Basic extensions
• generally, OS-level code, like Things

Is there any good reason to pull in library code like printf, scanf, floating point math or thelike?

Definitely not. So, the answer to your problem is easy: When creating code that is intended to go into ROM, or, more generally, code that is intended to extend the OS in any way, you tend to avoid using the C standard library like the pest. You would very probably not even use the standard C startup code. All of this code is bloated for generality, something that you don't need and don't want in OS extensions, occupying precious ROM space.

The only thing you will probably need from the library is code to execute system traps and vectors - And that's written in a position-independent way using only the stack for data, I checked.

I'm afraid I can't see the problem.

In my opinion, writing programs for the standard QL should be done in assembly anyways. Faster machines are fine with C or other high-level languages, but then you really don't need to jump through loops do save memory that's readily available en masse on these machines.

In case someone absolutely needs to produce C code that runs as a "pure" program, there's always the C68 library source code - It's portable enough that it should readily compile using PDQ or MCC C (it's first incarnations were built using these compilers)

Tobias

I do not agree. An example is e.g. The Editor. It's a very good editor (the only one supporting column blocks afaik), but it has the disadvantage (e.g. compared to MasterSpy) that it can only edit one file, and it's not reentrant. If you want to edit more files, you must start a full copy for every file. As it's size is >100K this consumes a lot of memory. If it would be reentrant, you could HOT_CHP it and run many copies of it, with the code just loaded once.

This is the reason, why I use SEDIT as my editor for simple things (like viewing files), cause as a QLiberated program it's reentrant an I can run many instances without eating up memory in the TPA. Another example are the PSION programs, which can also be HOT_CHPed (not so important now, where we have XCHANGE, which can edit more than one file).

I don't know or use the hotkey systems but pjw pointed out:

pjw wrote:On a Hotkey which loads the code into memory, you will always have N + 1 copies of the code in memory,
where N is the number of copies of the code actually executing.

So doesn't this suggest even with Hotkey you are not saving memory?

I also don't use MasterSpy or SEDIT...are they written to open multiple internal buffers for different text files?

bwinkel67 wrote:I don't know or use the hotkey systems but pjw pointed out:

pjw wrote:On a Hotkey which loads the code into memory, you will always have N + 1 copies of the code in memory,
where N is the number of copies of the code actually executing.

So doesn't this suggest even with Hotkey you are not saving memory?

Well, on a hotkey "which loads code into memory" you do.
On a hotkey which runs a Thing you don't.

It's hard to explain what HKII does in a few sentences - Best read the manual. It's on Dilwyn's site.

bwinkel67 wrote: I also don't use MasterSpy or SEDIT...are they written to open multiple internal buffers for different text files?

Nop, they don't, and they don't need to. Concepts like multiple internal buffers are something that is sort of obsolete when you use SMSQ/E - If you put the program in a Thing (that's what HK II does), you can run multiple processes (jobs) on the same code working with multiple documents. That's what Peter is referring to above -
Puts MasterSpy on hotkey <ALT>+"m" and loads it as a Thing into memory. Everytime you press the hotkey now, a new job will be started on that Thing (no additional code loaded) that can work as a stand-alone program with its own data space and file to edit. Code will be shared between the instances, data and stack will be separate.
That was really useful when you worked with floppy disks and could load all your essential programs on startup as Things, and could change to another disk - Even if the disk containing MasterSpy had long left the drive, you could still run a new instance and edit a new file. It's less crucial (still useful, though) on systems that have basically instant hard-disk (or SD) access and huge amounts of memory like Q68 or QPC2. Hotkey-loaded QLs with lots of memory (like a TrumpCard or GC/SGC) basically "feel" like everything's run from ROM.

Tobias

tofro wrote: Nop, they don't, and they don't need to. Concepts like multiple internal buffers are something that is sort of obsolete when you use SMSQ/E - If you put the program in a Thing (that's what HK II does), you can run multiple processes (jobs) on the same code working with multiple documents. That's what Peter is referring to above -

That's pretty cool. So you are not duplicating the code just giving a separate stack area and the heap is the heap which you just share (or maybe you create your own heap area out of the common heap to avoid fragmentation). I should play around with ZXSimulator to see if I could run multiple copies that way. It sounds like SMSQ/E allows for Things without HotKey.

bwinkel67 wrote:It sounds like SMSQ/E allows for Things without HotKey.

You don't need SMSQ/E for that - That's Hotkey System II, a module of the Pointer Environment, which can run on plain QDOS as well. HKII is an integral part of SMSQ/E.

BTW, where is "Thing" officially defined. I just looked through Dilwyn's SMSQ/E link and it refers to it but there doesn't seem to be a "a Thing is a blah, blah, blah" so one can get their bearings.

tofro wrote: You don't need SMSQ/E for that - That's Hotkey System II, a module of the Pointer Environment, which can run on plain QDOS as well. HKII is an integral part of SMSQ/E.

Oh so the "Thing" concept was created by HKII...I will look at its documentation. Just had no interest in hotkeys so that's why I've reading its documentation.

bwinkel67 wrote:I don't know or use the hotkey systems but pjw pointed out:

pjw wrote:On a Hotkey which loads the code into memory, you will always have N + 1 copies of the code in memory,
where N is the number of copies of the code actually executing.

So doesn't this suggest even with Hotkey you are not saving memory?

The N + 1 is only for none-re-entrant, ie "impure" code. The reason being that, er, the code is none-re-entrant.
I dont know about HOT_LOAD. To me, there seems no obvious reason why N + 1 copies are required for re-entrant code.