Alternatives to C68

Anything QL Software or Programming Related.
mhanias
Brittle Membrane
Posts: 105
Joined: Mon Jul 11, 2011 10:12 pm

Alternatives to C68

Post by mhanias »

Are there alternative c68 compilers that support float numbers?

Michael


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

Re: Alternatives to C68

Post by tofro »

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.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Artificer
Brittle Membrane
Posts: 120
Joined: Fri Nov 24, 2017 8:43 am

Re: Alternatives to C68

Post by Artificer »

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


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

Re: Alternatives to C68

Post by tofro »

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.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
bwinkel67
QL Wafer Drive
Posts: 1187
Joined: Thu Oct 03, 2019 2:09 am

Re: Alternatives to C68

Post by bwinkel67 »

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.


User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: Alternatives to C68

Post by NormanDunbar »

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.


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
Derek_Stewart
Font of All Knowledge
Posts: 3928
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: Alternatives to C68

Post by Derek_Stewart »

Hi,

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


Regards,

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

Re: Alternatives to C68

Post by tofro »

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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Alternatives to C68

Post by Peter »

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.


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

Re: Alternatives to C68

Post by ql_freak »

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://qlforum.co.uk/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.


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