Turbo compiled Apps in ROM...

Anything QL Software or Programming Related.
User avatar
tofro
Font of All Knowledge
Posts: 3007
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Turbo compiled Apps in ROM...

Post by tofro »

XorA wrote: Tue Feb 18, 2025 11:17 am
tofro wrote: Tue Feb 18, 2025 10:42 am
Peter wrote: Mon Feb 17, 2025 3:39 am
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.
No, I'm not. I'm only talking about C68 on QDOS, a soefific implementation on a very specific operating system. And I'd guess a few fingers would be enough to count the active developers there.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Peter
Font of All Knowledge
Posts: 2391
Joined: Sat Jan 22, 2011 8:47 am

Re: Turbo compiled Apps in ROM...

Post by Peter »

tofro wrote: Tue Feb 18, 2025 10:42 am Then you maybe were just lucky or your programs don't use static variables.
I have to program correctly of course. Which means that in most cases the stack is used. Static/global variables only where I actually want the data to be shared, in some cases including locking to make access atomic.
tofro wrote: Tue Feb 18, 2025 10:42 am Are you really sure you're sharing code between jobs (i.e. use the Hotkey system)?
Absolutely. In most cases I set up C functions as dependant jobs with a little assembler routine. These jobs share the workspace of their parent. "JOBS" under S*Basic shows them all. They call various shared, reentrant funtions. Never any problems with C68 or qdos-gcc producing reentrant code. I don't use the Hotkey system though.


User avatar
tofro
Font of All Knowledge
Posts: 3007
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Turbo compiled Apps in ROM...

Post by tofro »

Peter wrote: Tue Feb 18, 2025 1:57 pm Absolutely! In most cases I set up C functions as dependant jobs with a little assembler routine. These jobs share the workspace of their parent. "JOBS" under S*Basic shows them all. They call various shared, reentrant funtions. Never any problems with C68 or qdos-gcc producing reentrant code. I don't use the Hotkey system though.
Ah. Now we're getting close. You're kicking off the jobs from your own program after it has been relocated, so never run through the relocation routine twice. Hotkey would simply jump to the start address of your program twice, which would obviously kick in a second relocation.

So, we're talking "re-entrant programs" controlled by Hotkey System 2 vs. "re-entrant jobs" controlled by your own "master program". Obviously two different things. And if you kick off a job from your own program, you obviously want to share the data space with your parent job. Hotkey system 2 obviously doesn't want this.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Peter
Font of All Knowledge
Posts: 2391
Joined: Sat Jan 22, 2011 8:47 am

Re: Turbo compiled Apps in ROM...

Post by Peter »

tofro wrote: Tue Feb 18, 2025 2:18 pm Hotkey would simply jump to the start address of your program twice, which would obviously kick in a second relocation.
Ah, that's why you talked multiple relocations.
tofro wrote: Tue Feb 18, 2025 2:18 pm So, we're talking "re-entrant programs" controlled by Hotkey System 2 vs. "re-entrant jobs" controlled by your own "master program".
Yes, the jobs do not need to be derived from the same master program though. Reentrancy is also given if the shared functions are called from separate programs. (Obviously that requires a suitable calling mechnism.)


Post Reply