Turbo compiled Apps in ROM...

[tofro]

<>
I guess the file you are referring to is contained in the Turbo Manuals package from the late George Gwilt in https://github.com/SinclairQL/GeorgeGwi ... rbom16.zip , called "TurboRep.txt"

Thats the one. It looks like trbom16 contains the complete collection. Its pretty esoteric stuff, but could be useful for research purposes. Ideally, they shouldnt be hidden away in obscure repositories..

Well, we have to thank Norman for saving these documents at all in the first place. The GitHub repo is basically a replica of George's home page (also structure-wise), and I guess Norman just couldn't be bothered to re-sort and re-pack everything.

[RalfR]

From "turbos4_txt", Line 2375:

TURBO and SUPERCHARGE compiled programs contain internal data-areas
which are used to keep track of data very quickly 'on the fly' as a
program runs, so they cannot run in ROM. There again, it is easy to
copy a compiled task into ROM and copy it back to RAM when you want to
execute it. This makes sense because the internal data-areas almost
always save more time than ROM storage would, especially if you have
fast memory.

[NormanDunbar]

Well, we have to thank Norman for saving these documents at all in the first place. The GitHub repo is basically a replica of George's home page (also structure-wise), and I guess Norman just couldn't be bothered to re-sort and re-pack everything.

Afternoon all.

When I heard the sad news of George's death, I decided that I better download everything I could from George's web page in case it vanished. I noticed some stuff had already vanished so I went through all of George's code on my laptop/QPC2 setup and collected everything I had, sorted them into whatever version details I could extract from the sources and binaries, and labelled them as such. I then created a sub-directory for each application and saved all sources and binaries that I had, or was able to obtain, in that location.

I did actually spend a lot of time collating everything. Of course, it's not perfect, but not long after George's death, his online presence vanished.

I should note, if the repo replicates Georges web site in any way then that is purely coincidental as I didn't set out to do that, simply to preserve the software.

If I remember correctly, Graeme Gregory (XorA) collected Georges QL stuff and software and was cataloguing everything as and when time permitted. My effort was merely a "just in case" - a bit like what is happening with many Government websites and databases over in the USA at the moment as people try to save what they can in a limited time space.


HTH

Cheers,
Norm.

[pjw]

<>
I still have these documents if you are interested. Im sure SNG wouldnt mind if I passed them on to someone for a good cause, though I wouldnt make them generally available without his permission. Tim might have more, and a better idea of what might be useful for this endeavour..
<>

I guess the file you are referring to is contained in the Turbo Manuals package from the late George Gwilt in https://github.com/SinclairQL/GeorgeGwi ... rbom16.zip , called "TurboRep.txt"

Thats the one. It looks like trbom16 contains the complete collection. Its pretty esoteric stuff, but could be useful for research purposes. Ideally, they shouldnt be hidden away in obscure repositories..

Well, we have to thank Norman for saving these documents at all in the first place. The GitHub repo is basically a replica of George's home page (also structure-wise), and I guess Norman just couldn't be bothered to re-sort and re-pack everything.

Thanks indeed to Norman for saving these documents on GitHub. Naturally, even greater thanks are due to Simon for producing them in the first place, and to George for conscientiously collecting them for posterity.

I humbly beg pardon for drawing attention to these documents here, and for expressing a simple, constructive opinion implying neither criticism nor ingratitude.

Moving on: I hope they are proving to be of interest to those concerned!

[Derek_Stewart]

Hi,

All the Turbo Manuals quoted has been available on the QL Homepage for quite a while.

[Peter]

@Peter: Both Metacomco C and C68 actually can produce reentrant code - Just not by default. You need to tell them to create position-independent code and you need to provide your own libraries and startup code (or be very, very careful what you link to your program).

Reentrancy and position independency are different issues. Even C68 code generated with the default settings can be reentrant.

[tofro]

@Peter: Both Metacomco C and C68 actually can produce reentrant code - Just not by default. You need to tell them to create position-independent code and you need to provide your own libraries and startup code (or be very, very careful what you link to your program).

Reentrancy and position independency are different issues. Even C68 code generated with the default settings can be reentrant.

Yes, indeed they are different issues. But on the QL, that has no relocating loader built into the system, it basically boils down to the same thing. Non-PIC programs need to relocate themselves, leading to self-modifying code, which, given that the existing relocation libraries are not clever enough to withstand a second or further relocation attempt initiated by the C startup code, makes C68 programs that use the standard relocation routine non-reentrant.

You could maybe build a more clever C68 relocation routine that relocates in supervisor mode and makes sure it does it only once and not on subsequent calls through some sort of safeguard flag. This would protect the program from attempts to relocate it more than once and make it indeed somewhat re-entrant. This still leaves the problem that static and initialized variables live at absolute addresses in standard C68 code - If you are not very, very careful, multiple jobs running on the same code will still mess up their variables. (data model=small puts evening in the data space and addresses variables via a5)

[Peter]

Reentrancy and position independency are different issues. Even C68 code generated with the default settings can be reentrant.

Yes, indeed they are different issues. But on the QL, that has no relocating loader built into the system, it basically boils down to the same thing. Non-PIC programs need to relocate themselves, leading to self-modifying code, which, given that the existing relocation libraries are not clever enough to withstand a second or further relocation attempt initiated by the C startup code, makes C68 programs that use the standard relocation routine non-reentrant.

I roughly know how the C68 startup code works, still I can not follow your thought. Why should I want to relocate repeatedly? The initialization of the code needs to happen only once. After that, all routines are reentrant. I have often used the reentrancy of C68 code, various jobs using the same code.

[tofro]

Reentrancy and position independency are different issues. Even C68 code generated with the default settings can be reentrant.

Yes, indeed they are different issues. But on the QL, that has no relocating loader built into the system, it basically boils down to the same thing. Non-PIC programs need to relocate themselves, leading to self-modifying code, which, given that the existing relocation libraries are not clever enough to withstand a second or further relocation attempt initiated by the C startup code, makes C68 programs that use the standard relocation routine non-reentrant.

I roughly know how the C68 startup code works, still I can not follow your thought. Why should I want to relocate repeatedly? The initialization of the code needs to happen only once. After that, all routines are reentrant. I have often used the reentrancy of C68 code, various jobs using the same code.

Then you maybe were just lucky or your programs don't use static variables. The crt routines relocate the code, then "relocate" addresses of uninitialised data into QDOS heap memory. In order to keep the .DATA segment separate between jobs, they would have to copy initialised data (which is part of the executable) into job-specific memory (or the data space). But they don't, at least not as far as I can see.

Also, the "base pointer" to that allocated job-specific bss memory mentioned above is stored in the .TEXT segment (i.e. 'shared' code area, see crtdata.x in the run-times sources). That would make all instances of jobs running on this code use the same bss area.

Are you really sure you're sharing code between jobs (i.e. use the Hotkey system)?

[XorA]

Yes, indeed they are different issues. But on the QL, that has no relocating loader built into the system, it basically boils down to the same thing. Non-PIC programs need to relocate themselves, leading to self-modifying code, which, given that the existing relocation libraries are not clever enough to withstand a second or further relocation attempt initiated by the C startup code, makes C68 programs that use the standard relocation routine non-reentrant.

I roughly know how the C68 startup code works, still I can not follow your thought. Why should I want to relocate repeatedly? The initialization of the code needs to happen only once. After that, all routines are reentrant. I have often used the reentrancy of C68 code, various jobs using the same code.

Then you maybe were just lucky or your programs don't use static variables. The crt routines relocate the code, then "relocate" addresses of uninitialised data into QDOS heap memory. In order to keep the .DATA segment separate between jobs, they would have to copy initialised data (which is part of the executable) into job-specific memory (or the data space). But they don't, at least not as far as I can see.

Also, the "base pointer" to that allocated job-specific bss memory mentioned above is stored in the .TEXT segment (i.e. 'shared' code area, see crtdata.x in the run-times sources). That would make all instances of jobs running on this code use the same bss area.

Are you really sure you're sharing code between jobs (i.e. use the Hotkey system)?

Your basically arguing that something C programmers do thousands of times a day, in OSes and bare metal all over the world is impossible.

CRT is normally only for if your making executables. I haven't dug too deeply into c68, but considering C is a stack based environment generally you can jump to a C function as long as the SP is valid.