The Sinclair QL Forum

Are there alternative c68 compilers that support float numbers?

Michael

Metacomco/Lattice C is a possible alternative.
Uses a ROM module as copy-protection and is still under its original licence (i.e. can only be sourced used and must be bought). Note however, that this is an old-style, very pre-ANSI compiler.

But was definitely the best at its time.

Hi,

Digital C SE, a development of a small C compiler can support floating point numbers. Now freeware on Dilwyn Jones site as digic.zip download. Not as sophisticated C compiler as C68.

Cheers

Artificer wrote: Not as sophisticated C compiler as C68.

Agree. That's probably true in various degrees for all C compilers for the QL. C68 was the last one and still is the most sophisticated one.

Digital C does a pretty good job. Floating point doesn't get supported directly but via a library and a 3 element integer array, but you could use #define to create a float type (or FLOAT if you want to follow standard convention for using #define).

My experience is that if you write in Digital C (and I use the SE version), it's seamless to port over to other compilers. I've done it to Think C on the Mac back in the 90's. I just wrote some simple code and ported it over to the Amiga using Aztec C and really, I only had to change "_" to "." and for memory allocations over 64K use the specialized mlalloc with long integers. Oh and NULL is defined differently in stdio_h. Still, it took no time to get it to work, plus, on an unexpanded QL it actually compiled the same code quicker than on an unexpanded Amiga 500 (the Amiga had a 68000 so it should run close to twice as fast).

Now going from an ANSI C to Digital C will be problematic since it will run into trouble with non-supported things, especially complex structures.

mhanias wrote:Are there alternative c68 compilers that support float numbers?

C68 supports floats, as far as I remember, in IEEE 32 bit standard format. It also supports QL floats in various library calls etc. What problem are you having with floats?

bwinkel67 wrote:Digital C does a pretty good job. Floating point doesn't get supported directly but via a library and a 3 element integer array, but you could use #define to create a float type (or FLOAT if you want to follow standard convention for using #define).

I'm afraid I disagree. I bought Digital C SE years ago, after using it a few times, it was consigned to the deep! Floating point, as an array of 3 integers is pants, and performing arithmetic with "floats" is bonkers!

bwinkel67 wrote:My experience is that if you write in Digital C (and I use the SE version), it's seamless to port over to other compilers.

Until you get into file handling. Digital C's implementation of fopen, returns an int. Standard C's implementation returns a FILE *.

bwinkel67 wrote: ... Oh and NULL is defined differently in stdio_h.

True, NULL is defined as 0x8000 an address which "doesn't exist", to get over the fact that address 0, the usual NULL, does exist on the QL. However, 0x8000 is 32768 or -32768 if signed, and also exists. Obviously it's difficult to assign a non-existent address to NULL when all the addresses potentially exist on a QL. Is address 0x8000 outside the valid range of a Digital C compiled program? If so, then fine, otherwise we have the same problem as using address 0.

Also, I can't have nested structs.

bwinkel67 wrote:Now going from an ANSI C to Digital C will be problematic since it will run into trouble with non-supported things, especially complex structures.

Agreed, 100%.


Cheers,
Norm.

Hi,

How much work would involved converting Small C to ANSI C?

Derek_Stewart wrote:Hi,

How much work would involved converting Small C to ANSI C?

Lots. I think that was the main achievement behind C68 to get so close to ANSI, closer than any other C compiler for the QL. Note that "ANSI C" is not a real standard, and C68 only covers some of this. I can't see why someone would want to develop a new C compiler for the QL today.

The "standard" C compiler is C89/C90 compliant, something C68 isn't. Today we're at C18 (passed over C99, C11 to C18, the numbers are the years) which is even further away.

Tobias

tofro wrote:I can't see why someone would want to develop a new C compiler for the QL today.

What would still make sense IMHO, is a native qdos-gcc. The performance gap between C68 and qdos-gcc code is large, but cross-compiling somewhat restrictive.

I'm still fiddling with EJC (DO NOT LOOK FOR IT, you can only download it from my homepage, BUT: WITHOUT THE NECESSARY P_A_T_C_H_E_D Lattice compiler). C68 is a good compiler, I'm still trying to get it to work with the EJC libraries. This would mean, we would have a compiler which is ANSI compliant (only the compiler, NOT the EJC libs) and can produce reentrant, ROMable code. I think reentrant code is much more important on a QL (HOT_CHP) than a compiler, producing faster code.

Unfortunately, I have currently no time to work on it. First I must setup my "new" notebook (I'm currently fiddling with the docking station) (see https://theqlforum.com/viewtopic.php?f=9&t=3404).

BTW: Does anyone has contact information from Erling Jacobsen? It would be great if we would have the source of the libs and the startup code.