Contact to Metacomco (and Lattice!) because of their C Development Kit? (The Lattice C compiler)

[ql_freak]

Does anyone have contact to Metacomco? It would be nice, if the Lattice C compiler (I think it was based on Lattice V3.04 [or 5]) could be made "freeware" (must not be open source, it would be sufficient, if one could upload it somewhere and anyone can download it and may patch it).

Then anyone could use the superb EJC (Erling Jacobsen C) which is capable to produce reentrant, ROMable code (and is still fully compatible with K&R C[!], which is NOT true for other compilers, e.g. from Digital Precision).

Of course we could ask Lattice directly, but if we do not have the permission from Metacomco (I think they did the port to the QL), Lattice will tell us that they cannot do it, because Metacomco must also agree. So it would be nice if we have a written permission from Metacomco first, then we can ask Lattice (if the Lattice people do not agree, there's no chance).

p.s.: Of course we must ask Erling, if he agrees. But I think, this should (hopefully) be the smallest problem, as EJC IMO never was a commercial product.

p.p.s.: The Lattice C version used in Metacomcos development kit is even an improved version of K&R C: It supports function prototypes (but not in the ANSI C style) :‑DDDDDD A really great help when writing a C program.

[ql_freak]

Just read (README_txt) from EJC: The Lattice Compiler Metacomco used is Version 3.0.1.

BTW: In the attachement, you will find all text files from my (pimped) EJC distribution.

And here my README.txt, which I added to the above distribution in the attachement:

Code: Select all

This is EJC (Erling Jacobsen C)

I received it from Jonathan Hudson and it seems some additions
are from him.

EJC requires phase 1 and phase 2 from "Metacomco QLC Development
Kit", i. e. the Lattice C Compiler Phase 1 and 2 Version 3.01,
which ARE NOT INCLUDED in this archive(!).

Phase 1 is named QLC_1, size 82774, file type 1, dataspace 1024
Phase 2 is named QLC_2, size 83046, file type 1, dataspace 1024
dataspace returned from print fdat(\'RAM1_QLC_n'): REMark n = 1, 2

I don't know if the compiler phases of EJC are patched. I have
found my Phases of the Lattice C compiler which are named p1
and p2 and are of filetype 0. This may work, as in original you
needed a ROM with the SuperBASIC commands LC1 and LC2 which
loads the compiler from the MDV. Unfortunately I cannot look
how the compiler phases are named on original medium, cause
I first must refelt my Microdrive cartridges. I won't risk
to destroy the original cartridges, and up to now I have
not succeeded in refelting cartridges. When I have
successfully refeltet some cartridges, I will refelt the
original cartridges, and will tell you the size, type (and
if needed the dataspace) of the phases.


Advantages of EJC over C68

Erling has written a complete new library which allows usage
of -b (phase 1) and -r (phase 2) - it's IMHO default on EJC -
which IS NOT usable with the library of Metacomco. This means
EJC will produce position independent code, which MUST NOT
be relocated (as with original Library or C68). The code is
reentrant and (as stated in "ejc_txt") even ROMable.

I have until now just compiled my first hello world and am
still experimenting.

To compile a hello world use:

DATA_USE'WIN1_bin_ejc': REMark assuming WIN1_bin_ejc is stored here
REMark store your hello_c in the same directory
ex'cc';'cc hello': REMark the "cc" after ";'" IS REQUIRED(!), but
REMark may be any string without whitespace
WSTAT'hello'

After the last WSTAT command you should find a file "hello" which
is executeable, assuming the file "hello_c" existed.

"hello_c" should look like this:


#include <stdio.h>

int main() {
    int c; /* character to get for the last getchar(), so that window doesn't close */
    printf("hello world\n");
    c = getchar();
    return 0;
}

/* END OF FILE */

 
Last but not least: I cannot find any licence statement in any of the attached files. From none of the two authors.
 
 

[XorA]

What is wrong with c68 which is open source?

[ql_freak]

C68 and its Libraries do not create reentrant, ROMable code, the code is not even position independent, it needs a relocation module which relocates (adjust) all addresses when it's loaded to an address. Albeit the C68 compiler itself has options, similar to that of Lattice C which would allow to create reentrant code, the startup module and the Libs do not support it. And even in the case, that the calling conventions of e.g. functions would be compatible to Lattice C (I'm afraid not), so that one can use the EJC-Libs and startup module, it's questionable, if those options will work correctly, as they have not been tested/used until now (at least not in the QL version).