EJC (C-Compiler) experiments

Anything QL Software or Programming Related.
User avatar
bwinkel67
QL Wafer Drive
Posts: 1187
Joined: Thu Oct 03, 2019 2:09 am

Re: EJC (C-Compiler) experiments

Post by bwinkel67 »

Derek_Stewart wrote: Can you give an example of reentrant code, so that a comparison can be made.
So most any function can be rentrant as it adheres to the 3 rules of reentrancy:

Code: Select all

int doubleIt (num)
{
   return num * 2;
}
But perhaps thinking of recurisve calls makes it easier to conceptualize:

Code: Select all

int factorial (num)
   int num;
{
   if (num > 0)
      return num * factorial(num-1)
   else
      return num;
}
I think the bigger question is what is not reentrant and Wikipedia gives a bunch of examples that show the difference between reentrant and thread-safe since reentrant doesn't have to deal with concurrency/multi-threading.

https://en.wikipedia.org/wiki/Reentrancy_(computing)

If you go to stackoverflow there is lots of discussion but no definitive word as part of the problem deals with perspective, I suppose :-/ One simple discussion to compare a recursive function to a reentrant function forces the point of concurrency but then a commenter on the top answer rightfully points out that's not the case.

https://stackoverflow.com/questions/261 ... ction-in-c

I think the other issue lies on how you look at code. If you think of in term of a high level language there a lots of stops in place to compartmentalize your code (and we hope the compiler keeps that in place) but if you look at it as a machine code programmer then those barriers are more easily broken and the idea of reentrancy can become more difficult to initially ascertain.


User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: EJC (C-Compiler) experiments

Post by pjw »

Sooo much confusion! Perhaps its not strange, since there never was one big book
that explained it all; one sort of had to pick it up by a process of osmosis
over the years.

To my understanding, the following concepts apply to Qdos and SMSQ/E, whatever
the formal definitions my be in other universes:

Position independent code:
This is code that can be run from anywhere in memory as all addresses are
defined in the form of offsets from the current (or some other relative)
address: Say your address is Strand 24, and you want to send your messenger to
Strand 22. If you tell him Go To Strand 22, thats an absolute address. If you
tell him to go 2 doors down, thats relative.

Re-entrant code is code that does not modify itself at runtime. Multiple
instances of the job or task can be run using the same code in the same
location. Each instance will have its own stack and data. Thus you may have five
jobs called Files xxxx, each one executing the same code, but displaying
different directories.

Such code is also said to be ROMable.

If the code is ROMable, it means that the code can run from ROM; no extra copy
of the code in RAM is required.

Relocatable code:
This is code that is not position independent of itself. There will be a table
of locations that need to be resolved. Once it is loaded into memory, it needs
some startup code to resolve those addresses before it can be executed.

Multiple copies of the code must be loaded for multiple copies to run. If the
code is located in ROM, it must first be copied to RAM. 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.

If the Hotkey System doesnt recognise such code itself, you can force it into
treating the code as Impure with the I - option.

(In theory, once such code has been prepared for execution (addresses resolved)
it could, conceivably, be re-entrant, with certain caveats.)

HOT_RES vs HOT_CHP. These do not refer to different addressing modes, but to
different areas in memory. The RESident Procedure area is reserved for stuff
that is loaded at boot time and that is not to removed throughout the whole
session. HOT_RESed Things go there, along with drivers, toolkits and the like.

HOT_CHPed Things may be removed, as thay are located in the Common HeaP, which
has more flexible memory management. Normally, once jobs are running, the RPA is
not longer accessible, so HOT_RES will simply put Things in the CHP instead. The
reasons for all this are beyond the scope of this little exposition.


Per
dont be happy. worry
- ?
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: EJC (C-Compiler) experiments

Post by tofro »

Good summary, Per. That's my understanding as well.

C68 code could probably be made to run as "pure" jobs when the relocation routine would be changed in a way that it would keep a flag "this code has been relocated already" and run the actual relocation in supervisor mode (i.e. aromic). The second job running on the same code would then just skip the runtime relocation.

No idea if this would be worth the effort, though. The original developers have apprently considered this a "no".


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: EJC (C-Compiler) experiments

Post by pjw »

In my piece above the implied assumption is we're talking assembler/machine code. I assume that higher level languages are inherently re-entrant (unless someone goes to quite a lot of trouble to make them not so.)

One could argue that line numberless S*BASIC is not inherently "re-locatable" if RESTORE, GO XXX etc are used, but apart from that most high-level languages should be both relocatable and re-entrant. It is what compilers of such languages makes of them that causes the problems.


Per
dont be happy. worry
- ?
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: EJC (C-Compiler) experiments

Post by pjw »

tofro wrote:Good summary, Per. That's my understanding as well.<>
Thanks, Tobias. Your own comments are usually highly knowledgable and clarifying, and very often more precise than any I could make.

Which reminds me: In my comment above I meant to say "I assume that programs written in higher level languages are inherently re-entrant (unless someone goes to quite a lot of trouble to make them not so.)"


Per
dont be happy. worry
- ?
Derek_Stewart
Font of All Knowledge
Posts: 3928
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: EJC (C-Compiler) experiments

Post by Derek_Stewart »

Hi,

Thank you for the simipilified answer to all this, I must admit to being confused by the Wikipedia explanation or Reentrant code.

When I write simple C68 programmes for my own enjoyment, in general they are executable programmes that produce a Job Name an multi tasks based on the priority set.

I can execute many different copies of the same same programme which all have different Job Names.

I am not sure about this, but is QDOS/SMSQ/E handling the re-entrant code problem, assuming the code is defined as clean executable programme?


Regards,

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

Re: EJC (C-Compiler) experiments

Post by tofro »

Derek,

unless you don't want to start your programs using HOT_CHP or HOT_RES (which makes them execute as a thing), or are writing device drivers or, generally, code intended to go into a ROM, but instead use the various variations of EX to start your programs, there's no need to bother with reentrancy. Impure programs which you want to execute as things need to be started with the "-I" option of the various HOT_ commands. Hotkey system II will then know the program is "impure" and handle it accordingly.

HOT_CHP and HOT_RES execute programs as Things, thus re-use the code segments to run multiple jobs on the same code. There, re-entrancy, or rather "purity" as Tony would say, is an issue.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Derek_Stewart
Font of All Knowledge
Posts: 3928
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: EJC (C-Compiler) experiments

Post by Derek_Stewart »

okay, I think I understand...

But I am not sure of the original question.


Regards,

Derek
User avatar
bwinkel67
QL Wafer Drive
Posts: 1187
Joined: Thu Oct 03, 2019 2:09 am

Re: EJC (C-Compiler) experiments

Post by bwinkel67 »

pjw wrote:In my piece above the implied assumption is we're talking assembler/machine code. I assume that higher level languages are inherently re-entrant (unless someone goes to quite a lot of trouble to make them not so.)
Thank you for the clear and concise summary. I don't think any of it goes beyond the normal understanding of the terms in computing (i.e. I don't think QDOS/SMSQE creates its own terminology thankfully). As you state here, perspective is important, and from a machine code perspective you aren't forced into boundaries that higher level languages put in purposefully.


User avatar
bwinkel67
QL Wafer Drive
Posts: 1187
Joined: Thu Oct 03, 2019 2:09 am

Re: EJC (C-Compiler) experiments

Post by bwinkel67 »

tofro wrote:Good summary, Per. That's my understanding as well.

C68 code could probably be made to run as "pure" jobs when the relocation routine would be changed in a way that it would keep a flag "this code has been relocated already" and run the actual relocation in supervisor mode (i.e. aromic). The second job running on the same code would then just skip the runtime relocation.

No idea if this would be worth the effort, though. The original developers have apprently considered this a "no".

Was C68 created from scratch or was it ported? (apologies for not having taken the time to actually look at it :-/) Curious why they chose this method. I've had the opportunity to write a couple of my own compilers, though not at the complexity of C, and made addressing relative in the object code (what we call position independent here) as it was simplest. Then when you link to a certain environment you take into account some absolute addresses. Not having done something in the complexity of C I can't offhand think at the moment what obstacles the language adds during code generation.


Post Reply