Page 3 of 3
Re: Development Systems and Created Code (reentrant, ROMable, ...)
Posted: Thu Jul 09, 2020 12:59 pm
by pjw
ql_freak wrote:pjw wrote:The following information may or may not be clear from the documentation. I have gathered
this through observation and testing, not by reviewing the code. Please correct anything
you know to be wrong:
Code: Select all
Command type Self modifying Copies in memory
HOT_RES/HOT_CHP impure N + 1
HOT_LOAD pure/impure N
HOT_RES/HOT_CHP pure 1
where N = number of instances running, 0..
I think this is (at least mostly) correct. <>
Id be very happy if you could point out the none-mostly bits

Re: Development Systems and Created Code (reentrant, ROMable, ...)
Posted: Fri Jul 10, 2020 12:01 am
by ql_freak
pjw wrote:I think this is (at least mostly) correct.
Id be very happy if you could point out the none-mostly bits :)
Unfortunately I am also not absolutely sure, if you are correct, but I think so. So I have used the "(at least mostly)" ;-)
Re: Development Systems and Created Code (reentrant, ROMable, ...)
Posted: Fri Jul 10, 2020 5:37 pm
by pjw
The info is certainly not complete, but then I was just trying to clear up a few
points that seemed to be causing confusion in the ranks. Things and Hotkeys seem
to me to be much underappreciated - largely because these "novel" concepts are
not well understood. No wonder, perhaps, as what information there is is dense
and scattered.
I just checked out what the "SuperBASIC Manual" had to say about these concepts
(Thanks for the reminder, Norman!) From the user point of view it gives a very
thorough description, with examples and caveats - the most detailed Ive seen so
far, so thats a good place to start (or to revise!)
For programmers, there is no best place to start! There is the Qdos/SMS
Reference Guide, of course. But unless you understand everything already, you
are unlikely to learn about it there! The only way I have found is by looking at
other's code, trying things out, and then trying to understand what Ive
done. But then Im not a professional programmer; some people will obviously
find it easier.
Re: Development Systems and Created Code (reentrant, ROMable, ...)
Posted: Sun Jul 12, 2020 4:01 am
by ql_freak
I now have had a look at
Digital Precision C (look for "digic.zip") and I assume (I'm not sure!) that it also produces reentrant (perhaps even ROMable) code, cause it addresses all its code via address register A6 :-)
It's not a full K&R C compiler, but what i have read, mostly missing is: It's not allowed to reference a struct inside a struct:
Code: Select all
struct aStruct {
int *count;
char *str;
}; /* NOTE(!): Here the semicolon is REQUIRED(!) A dangerous pitfall of C/C++ */
struct invalidDigitalPrecisionCStruct {
struct aStruct unallowedMemberOfStruct;
};
There is an interesting chapter how to interface with Assembler. The beginning is:
Code: Select all
5. WRITING MACHINE CODE FUNCTIONS FOR USE FROM C
Writing machine code functions for DIGITAL C SPECIAL EDITION is
sometimes desirable for efficiency in speed and size. The existence
of this section on technique is in no way indicative that Digital
Precision offer any support at all for the writing of machine code
functions - in fact, we WILL NOT answer any questions whatsoever on
this topic. This section is only for very experienced machine code
programmers who already have an excellent understanding of M68000
machine code, who are fluent with the use of assemblers and who are
prepared to experiment and able to solve their own problems. We
recommend the use of the HiSoft assembler and our own IDIS SPECIAL
EDITION. Now you are on your own.
Reread section 4.16.4 .
5.1 Intermediate code
The DIGITAL C SPECIAL EDITION parser cc outputs a compact intermediate
code which is translated into 68008 machine code by the Code
Generator/ Linker, cg. The intermediate code consists of single byte
instructions followed by 0, 1 or 2 parameters. For example:
push pushes a value onto the stack and has no
parameters
load "name" loads the value of the variable called "name"
into a register.
Because of the need to link separate modules together, and because
variables and/or functions referred to may be in different modules,
the names of variables and functions must be contained in the
intermediate code as ASCII strings. If you copy an "_obj" module to
the screen, you will see names intermingled in the code. It is the
task of cg to resolve all inter-module references. This contributes
to making writing machine code functions somewhat tedious!
5.2 Register usage
DIGITAL C SPECIAL EDITION compiled code does not use all the 68008
registers. However, the majority of the library functions supplied in
std_lib are in machine code. Hence it is sensible not to rely on
registers holding values between functions, except as described below.
Compiled code uses these registers:
A5 dsp Data stack pointer, used to point to the top of the data
stack, as distinct from the A7 stack. Ensure the value of
Unfortunately it seems, that DPC does NOT use standard SROF (Sinclair Relocatable Object Format – i.e. the GST Linker, which is also the native object format of the Atari ST), but an own. So most probably no chance to link it with the excellent GST Macro Assembler :-(
I'm currently working on a new EJC compiler driver (LCC – Lattice C Compiler driver) which uses the Lattice C from PDQC. It seems to have a lot of improvements, especially the -i command line option, which allows to specify include directories :-) I'm of good hope, that it can be used with the libs of EJC.
BTW: Is the mentioned HiSoft Assembler now freeware? If not, does anyone know the author? It's a good Assembler, Boris Jakubith (inventor of the HIST device - now even included [but limited] in QPC2) has used it as its standard assembler.
Re: Development Systems and Created Code (reentrant, ROMable, ...)
Posted: Fri Jul 24, 2020 10:33 pm
by RalfR
ql_freak wrote: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.
Nice to read

. I do not know, why programs make an effort to use several files, they simply should be reentrant, that's quite enough and also what TT always suggested. As long as all ASM included are reentrant (and they are in S_Edit), and QLib programs are, it will give no problems.
Re: Development Systems and Created Code (reentrant, ROMable, ...)
Posted: Sun Aug 09, 2020 3:57 am
by ql_freak
To understand what reentrance means:
Start QPC2 a second time...
Your boot program won't run (the WIN1_ is opened from first QPC2 AND LOCKED)
(That's very good, else it could be possible that 2 QPC2s will change the same harddisk at the same time from 2 different computers[!])
Reentrance would mean:
Both QPC2s use the same WIN1_, but are both capable to write on WIN1_ WITHOUT DESTROYING the data written by the other QPC2.
This is were you need a database. Files which were changed by both QPC2s must be stored separately for every instance of QPC2 - a horror to implement (without a good database; and even with a good database it's very difficult).
It's more easy in programming languages: You know which variables are read/write and which are readonly (the latter can be shared).
Re: Development Systems and Created Code (reentrant, ROMable, ...)
Posted: Sun Aug 09, 2020 9:39 pm
by mk79
ql_freak wrote:To understand what reentrance means:
Start QPC2 a second time...
Your boot program won't run (the WIN1_ is opened from first QPC2 AND LOCKED)
As an aside, you can do WIN_REMV 1 in your boot program, so two QPCs can share the same WIN file (of course not at the same time, but a WIN will be unlocked when no files on it are open, which works very well). This will be the default in the future.
Marcel
Re: Development Systems and Created Code (reentrant, ROMable, ...)
Posted: Tue Aug 11, 2020 11:34 pm
by ql_freak
Very nice!