EJC (C-Compiler) experiments

Anything QL Software or Programming Related.
User avatar
ql_freak
Gold Card
Posts: 354
Joined: Sun Jan 18, 2015 1:29 am

EJC (C-Compiler) experiments

Post by ql_freak »

When trying EJC (Erling Jacobsen C) you should read ejc_txt!

Albeit there seems to be a bug. If I use:

ex 'cc' , #1 , 'ram1_err_txt' ; 'cc -?'

the help file is written to 'RAM1_err_txt'

But if I use:

ex 'cc' , #1 , 'ram1_err_txt' ; 'cc hello': REMark You MUST NOT write the "_c" suffix (EJC cc is friendly and also allows ".c" :-)

(hello_c contains an error), the error message is NOT written to "RAM1_err_txt" :-(

Instead in SB-Window #1 just an error message ("Error in pass 1 when compiling hello") is written :-(

I have not found out, how to get the error messages of phase 1 of the Lattice compiler when using EJCs "cc" compiler driver :-(

When starting LC_1 directly with EX I have succeeded to get the error messages from LC_1 (missing semicolon).

Has anyone experience with EJC?

Seems to be a superb compiler :-) Albeit it seems to be not fully finished...


http://peter-sulzer.bplaced.net
GERMAN! QL-Download page also available in English: GETLINE$() function, UNIX-like "ls" command, improved DIY-Toolkit function EDLINE$ - All with source. AND a good Python 3 Tutorial (German) for Win/UNIX :-)
User avatar
bwinkel67
QL Wafer Drive
Posts: 1187
Joined: Thu Oct 03, 2019 2:09 am

Re: EJC (C-Compiler) experiments

Post by bwinkel67 »

Where can you find information on EJC C-Compiler?


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 »

Peter,


try

Code: Select all

EX CC,#1;"-c hello_c 2>ram1_error_txt"
That's how C68 does it.
Last edited by tofro on Tue Jun 23, 2020 7:10 am, edited 1 time in total.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
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 »

bwinkel67 wrote:Where can you find information on EJC C-Compiler?
Nowhere, I'm afraid.
It was apparently a rip-off of the Lattice C compiler of dubious legal status that circulated in the 90ies.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
ql_freak
Gold Card
Posts: 354
Joined: Sun Jan 18, 2015 1:29 am

Re: EJC (C-Compiler) experiments

Post by ql_freak »

tofro wrote:
bwinkel67 wrote:Where can you find information on EJC C-Compiler?
Nowhere, I'm afraid.
It was apparently a rip-off of the Lattice C compiler of dubious legal status that circulated in the 90ies.
It is absolutely legal if you own the original "Metacomco C Development Kit" (MCDK) which is based on the famous (at least at it's time, was also available for DOS, Atari ST and other machines) Lattice C compiler.

You can now download it from my homepage :-) The Lattice C compiler phase 1 and 2 are not included of course. So you must own the MCDK. Unfortunately I do not know, if the 2 phases have had been patched by Erling. Please read the file "README_txt" in the ZIP archive, which has more information.

Why do you want to use EJC (full K&R C compiler) when we have C68 (with more modern ANSI C)? Cause EJC will produce clean QDOS (SMSQ/E) code, i.e. position independent (no relocation needed), reentrant and even ROMable. It is eventually even be possible to write SuperBASIC extensions with EJC as the Lattice Compiler has an option to address all static and external data via address register A6 :-)

Use the following link (it's currently NOT linked in the left index column of my homepage, if I get a response, that the compiler runs with the Lattice compiler from MCDK, I will add it to the index column):

http://peter-sulzer.bplaced.net/htdocs/ ... loadEN.php


http://peter-sulzer.bplaced.net
GERMAN! QL-Download page also available in English: GETLINE$() function, UNIX-like "ls" command, improved DIY-Toolkit function EDLINE$ - All with source. AND a good Python 3 Tutorial (German) for Win/UNIX :-)
User avatar
bwinkel67
QL Wafer Drive
Posts: 1187
Joined: Thu Oct 03, 2019 2:09 am

Re: EJC (C-Compiler) experiments

Post by bwinkel67 »

Thank you. It seems to be a set of libraries and maybe a modified linker but no parser or code generator...I'm guessing that's phase 1 & 2. So the linker and new library is what changed with regard to Metacomco/Lattice C I'm guessing, making it position-independent. I don't own Metacomco C and it seems you needed a ROM to use it for copy protection, which would discourage me from owning it :-/ If the only difference is the linker then it must have been the way Metacomco implemented theirs that Erling didn't like and so created his own since I would figure that if the parser/code generator framework was grabbed from Lattice C then the only QL-specific part that Metacomco created was their linker.

Besides C68, the other C compiler that gets you pretty close to K&R's C, in my opinion, is Digital C 'SE' having used it extensively, though it unfortunately adds floating point through library calls rather than implement them directly. I have written code and ported it over to the Mac side back in the 1990's using Think C, which was a K&R C and little change was needed -- of course I avoided use of floating point on the QL side since it was non-standard, but I was just writing a prototype interpreter and it was trivial to add in with Think C. Another QL compiler, GST C, seems to be, like the original Digital C, integer only and those two seem very similar.

I will dig more into both EJC as well as C68 eventually but I'm presently on this "development on an unexpanded (err BB) QL" kick just to see what I could have created back in 1989 with what I had and what was available. Back then I had purchased the QL ($99) and Digital 'C' SE at the same time since I wanted to do some coding and it remained my only computer for about 5 years. If indeed the linker is at issue, I'm wondering if C68 could be modified to fix that same problem.

I'm not sure if Digital 'C' SE is position-independent as I'm not quite sure I understand its meaning with regard to compiled code...does it mean the linker adds a loader that then moves the code itself to somewhere else in QDOS memory upon EXECution? If so, why?


User avatar
ql_freak
Gold Card
Posts: 354
Joined: Sun Jan 18, 2015 1:29 am

Re: EJC (C-Compiler) experiments

Post by ql_freak »

bwinkel67 wrote:Thank you. It seems to be a set of libraries and maybe a modified linker but no parser or code generator...
I have written it in my post "The Lattice C compiler phase 1 and 2 are not included of course", and a WARNING is written in extra large letters on the download site, that you must own the Metacomco C Development Kit (MCDK).
bwinkel67 wrote:I'm guessing that's phase 1 & 2.
CORRECT
bwinkel67 wrote:So the linker and new library is what changed with regard to Metacomco/Lattice C I'm guessing, making it position-independent.
Only the library is changed. The linker is the same (perhaps a newer version) as in MCDK. The linker is no problem, as it is the Standard QDOS GST Linker from the GST assembler, which is now freeware (see Dilwyns Software Download page)[/quote]
bwinkel67 wrote: don't own Metacomco C and it seems you needed a ROM to use it for copy protection, which would discourage me from owning it :-/
NO! Metacomco C was never copy protected!. The ROM was absolutely necessary on an unexpanded QL, cause there was not enough room to load TK2 to get the "EX" commands. Even with the ROM, when running the compiler, the screen flickered (was destroyed in parts) on an unexpanded QL (i.e. the Screen memory was used as a temporary storage, to have enough RAM)
bwinkel67 wrote:I'm not sure if Digital 'C' SE is position-independent as I'm not quite sure I understand its meaning with regard to compiled code...
You can easily test this. Just try to HOT_CHP one of your programs and then start it multiply. If your QL doesn't crash, it's most probably reentrant (I think it mustn't be position independent, reentrant is more important). As I also own all programs (LEGALLY, I've bought them, when they sold all for a very cheap price) from Digital Precision, I would be interested, if DPC can produce reentrant, and perhaps even ROMable code.
bwinkel67 wrote:does it mean the linker adds a loader that then moves the code itself to somewhere else in QDOS memory upon EXECution? If so, why?
It's more complicated, but it's now too late to explain ;-)


http://peter-sulzer.bplaced.net
GERMAN! QL-Download page also available in English: GETLINE$() function, UNIX-like "ls" command, improved DIY-Toolkit function EDLINE$ - All with source. AND a good Python 3 Tutorial (German) for Win/UNIX :-)
User avatar
bwinkel67
QL Wafer Drive
Posts: 1187
Joined: Thu Oct 03, 2019 2:09 am

Re: EJC (C-Compiler) experiments

Post by bwinkel67 »

I don't use hotkeys but HOT_CHP claims to load an executable program into the common heap and Digital 'C' SE uses the common heap for its code. You can also EXEC the same program multiple times and it will run multiple independent copies (so it is reentrant). However, I would hope that's true of any QL compiler (i.e. I would imagine C68 does that as well).

You can test it yourself if you like. Find the ZXSimulator forum topic and grab the last zx.zip file and run the zx executable...it was compiled under Digital 'C' SE...


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

Re: EJC (C-Compiler) experiments

Post by bwinkel67 »

ql_freak wrote:NO! Metacomco C was never copy protected!. The ROM was absolutely necessary on an unexpanded QL, cause there was not enough room to load TK2 to get the "EX" commands. Even with the ROM, when running the compiler, the screen flickered (was destroyed in parts) on an unexpanded QL (i.e. the Screen memory was used as a temporary storage, to have enough RAM)
I'm terrified and intrigued by it using screen memory to do compiles :D. It was my misunderstanding when I read it required an EPROM to run that I thought it was copy protected -- also I think on one of the posts I found it was concluded that it used copy protection.

Digital 'C' SE runs nicely on an unexpanded QL and doesn't require TK2 as it just offers the command line in a dialog if you don't feed it in directly (though it will use the extended command line options of TK2). Back in the 90's I happily compiled using just the two microdrives in 128K and I've recently recreated that in May when I did a full compile of ZXSimulator on the actual QL with the only change being the use of vDrive instead of microdrives (so no ROM additions since vDrive doesn't add anything). It took a while to compile but that's because I stuck all 4 source files into a single one whereas in the 90's I actually had the linker (cg) link 3 different object files and used a header that tied it all together using the #ifdef directives (for some reason I haven't gotten the link component to work under QLAY2...something to do with how it works interacts with WIN and MDV drives I believe). However, no native floating point in Digital 'C' SE but they do offer a library of floating point functions so that part won't be standard.


User avatar
ql_freak
Gold Card
Posts: 354
Joined: Sun Jan 18, 2015 1:29 am

Re: EJC (C-Compiler) experiments

Post by ql_freak »

tofro wrote:try

Code: Select all

EX CC,#1;"-c hello_c 2>ram1_error_txt"
This creates 'ram1_error_txt', but the file is empty (length 0) :-(

As the source code for the cc compiler driver is delivered (I have had already compiled it successfully :-), I will have a look, what's going wrong.

Unfortunately there's one strcpy() function used (often), which I don't understand:

Code: Select all

int   compile(s)
char  *s;
{
   char  b[256];
   AJOB  jobs[1];
   int   retcode;
   char  *strcat(),*strcpy();
   void  viewfile(),deletefile();
   struct stat sb1,sb2;
   char  *cp;
   char  m[20];

   if( dflag )
      if( stat( strcat(strcpy(b,s),"_o"),&sb2 )==0 )
      /*               ^^^^^^^^^^^ */
 /* parameter s is declared in main with: char *s[32]; i. e. array of 32 pointers to char. It is initialised
 in a for loop with: s[sc++] = argv[i]+1; sc and i are declared as int. Then compile is called with:
   ec += compile(s[i]); where ec is the error count */
As b is of storage class auto, this array will not be initialised with 0. So when using strcpy(b,s), in my opinion this most often should crash. Where is my fault (cc doesn't crash)?

As written in original message ex'cc',#2;'cc -?' (-? is the option to print out help) prints the help text to SuperBASIC channel #2.


http://peter-sulzer.bplaced.net
GERMAN! QL-Download page also available in English: GETLINE$() function, UNIX-like "ls" command, improved DIY-Toolkit function EDLINE$ - All with source. AND a good Python 3 Tutorial (German) for Win/UNIX :-)
Post Reply