Which lean C compiler for 32-bit OS development

[James Harris]

Help! I've written a fair amount of C code over the years and always
interfaced it with other C. Now I'm looking to interface it with non-C
code I'm struggling to find a compiler to do what I want. I'm looking
for a compiler with these qualities:

* to compile standard, portable, C to object code
* simple object file output (not linked)
* Intel-format 32-bit asm output would be good
* selectable subroutine linkage options (calling conventions)
* simple demands on the OS so relatively easily ported to another OS
* works under various environments - Dos, Unix, Windows (without
Cygwin etc)
* reasonably effective at optimisation

and *above all*, a compiler that gets in the way as little as
possible. It should not compile for a certain target OS but merely
produce simple, lean, unencumbered, OS-agnostic object code, i.e.
object code that does just what the source code says and nothing more.

I'll generally link the object files together myself so a standard and
simple object format would be useful. I know most about Elf so that
would be ideal but not essential.

I've tried Open Watcom and gcc so far. Open Watcom is great at
providing different calling convention options but both Dos and
Windows versions have far too much mechanism surrounding them for my
liking and I can't get them to produce asm output. gcc is good on Unix
but looks very complex to port and I think it needs Cygwin on Windows.

In searching around I came across lcc and lcc-win. Remembering Jacob
posts here make me think about asking on this newsgroup. I hope the
query is just about close enough to being on topic! Any suggestions -
even partial matches to the list above - would be appreciated.

TIA,
James

 

[jacob navia]

Le 12/11/11 10:22, James Harris a écrit :

In searching around I came across lcc and lcc-win. Remembering Jacob
posts here make me think about asking on this newsgroup. I hope the
query is just about close enough to being on topic! Any suggestions -
even partial matches to the list above - would be appreciated.

You will find mostly negative answers about my work in this group.

Anyway my compiler system has been used extensively as a back end
For instance for the Eiffel language by the SmartEiffel compiler
by ML4 (a 4GL language) and as a JIT for an SQL--> C database
engine.

I guess a JIT would be much better for your needs. I have one
for Windows, Linux, AIX, or Macintosh.

jacob

 

[James Harris]

Le 12/11/11 10:22, James Harris a écrit :


You will find mostly negative answers about my work in this group.

On the contrary. I remember people here rightly jumping to your
defence when someone raised a criticism.

Anyway my compiler system has been used extensively as a back end
For instance for the Eiffel language by the SmartEiffel compiler
by ML4 (a 4GL language) and as a JIT for an SQL--> C database
engine.

I guess a JIT would be much better for your needs. I have one
for Windows, Linux, AIX, or Macintosh.

A JIT? You mean for platform independence? From the name I imagine lcc-
win32 is kind of tied-in to Windows too much for my purposes but I'll
take a closer look.

James

 

[jacob navia]

Le 12/11/11 11:09, James Harris a écrit :

On the contrary. I remember people here rightly jumping to your
defence when someone raised a criticism.


A JIT? You mean for platform independence? From the name I imagine lcc-
win32 is kind of tied-in to Windows too much for my purposes but I'll
take a closer look.

James

A JIT is just a code generator that doesn't generate any object file.

You pass it a string of C code and it will produce in memory an
executable function that you can call right away.

Much better than DLLs or shared objects.

 

[James Harris]

Le 12/11/11 11:09, James Harris a écrit :
....


....

A JIT is just a code generator that doesn't generate any object file.

You pass it a string of C code and it will produce in memory an
executable function that you can call right away.

I did say I wanted to generate object files.

Much better than DLLs or shared objects.

Maybe but not for this application!

James

 

[Nobody]

gcc is good on Unix but looks very complex to port and I think it needs
Cygwin on Windows.

It doesn't. MinGW is the standard "native" Windows port of gcc. The
standard 32-bit DOS port of gcc is DJGPP.

 

[BGB]

It doesn't. MinGW is the standard "native" Windows port of gcc. The
standard 32-bit DOS port of gcc is DJGPP.

however, getting GCC built from sources is still fairly difficult IME,
which could make it extra difficult to port to a new OS.

another downside is that it is often built in a form customized for a
particular target OS, meaning that using it as a cross compiler may
require building it from sources, and dealing with the usual hassles of
getting it built.

however, certain common combinations are fairly easy to get pre-built,
for example MinGW is available prebuilt on many Linux distros (as well
as its use on Windows), so if one is looking to cross-compile for an
environment using x86 and PE/COFF, then one may well be in luck.

typically, support for raw binaries is also available (in most GCC
builds I have seen), although I wouldn't "generally" recommend using raw
binaries without good reason.


it is also a fairly large and complex codebase (and difficult to make
sense out of).

also, some (many) people (myself included) find the GAS syntax to be
rather nasty (I personally much prefer Intel/NASM/... style syntax).

I am not certain if there is a way to get GCC to produce Intel-style
output (I think there may be, but I haven't really looked into it).


I also have my own C compiler, although I rather doubt it would be what
you are looking for (it is designed for JIT and working mostly in the
context of a VM, rather than producing statically-compiled standalone
code, and is also very buggy and is not well maintained at present...).


or such...

 

[ankh]

Help! I've written a fair amount of C code over the years and always
interfaced it with other C. Now I'm looking to interface it with non-C
code I'm struggling to find a compiler to do what I want. I'm looking
for a compiler with these qualities:

Troll alert!! Have the newsgroup participants been so boned that you can
post that lame of a bait and get bites?

 

[ankh]

Le 12/11/11 10:22, James Harris a écrit :

You will find mostly negative answers about my work in this group.

Anyway my compiler system has been used extensively as a back end
For instance for the Eiffel language by the SmartEiffel compiler
by ML4 (a 4GL language) and as a JIT for an SQL--> C database
engine.

I guess a JIT would be much better for your needs. I have one
for Windows, Linux, AIX, or Macintosh.

jacob

The song remains the same, huh jake.

 

[ankh]

Indeed.

RIP.

 

[James Harris]

....

however, getting GCC built from sources is still fairly difficult IME,
which could make it extra difficult to port to a new OS.

another downside is that it is often built in a form customized for a
particular target OS, meaning that using it as a cross compiler may
require building it from sources, and dealing with the usual hassles of
getting it built.

Do you know what would be needed in a new OS for it to run gcc? I've
never looked into it but I presume at least a clib for that OS would
be required. (The new kernel is not intended to support Unix system
calls, at least natively, though I could add a translation layer.)

however, certain common combinations are fairly easy to get pre-built,
for example MinGW is available prebuilt on many Linux distros (as well
as its use on Windows), so if one is looking to cross-compile for an
environment using x86 and PE/COFF, then one may well be in luck.

A few people have mentioned MinGW. The whole gcc thing is bulky but I
do like some of the code generation options it has such as pic, omit
frame pointer and various optimisations. I'd still rather define the
calling conventions myself but that's not something C programmers
typically want to do so is a bit off topic here.

typically, support for raw binaries is also available (in most GCC
builds I have seen), although I wouldn't "generally" recommend using raw
binaries without good reason.

it is also a fairly large and complex codebase (and difficult to make
sense out of).

also, some (many) people (myself included) find the GAS syntax to be
rather nasty (I personally much prefer Intel/NASM/... style syntax).

Me too.

I am not certain if there is a way to get GCC to produce Intel-style
output (I think there may be, but I haven't really looked into it).

gcc has had the -masm switch added to generate asm output in something
closer to Intel syntax. At least the operands end up in Intel order.

I also have my own C compiler, although I rather doubt it would be what
you are looking for (it is designed for JIT and working mostly in the
context of a VM, rather than producing statically-compiled standalone
code, and is also very buggy and is not well maintained at present...).

Yes, different requirements. Of the non-gcc compilers I've found so
far tcc looks most promising for being small and simple. Its object
code is far from optimised, though, (and is also in gas format).

James

 

[BGB]

...


Do you know what would be needed in a new OS for it to run gcc? I've
never looked into it but I presume at least a clib for that OS would
be required. (The new kernel is not intended to support Unix system
calls, at least natively, though I could add a translation layer.)

dunno, maybe the standard C runtime and some basic POSIX features?...

A few people have mentioned MinGW. The whole gcc thing is bulky but I
do like some of the code generation options it has such as pic, omit
frame pointer and various optimisations. I'd still rather define the
calling conventions myself but that's not something C programmers
typically want to do so is a bit off topic here.

unless there is a compelling reason, it is usually not a good idea to
use non-standard calling conventions.

Me too.


gcc has had the -masm switch added to generate asm output in something
closer to Intel syntax. At least the operands end up in Intel order.

yeah. never really messed with it much personally...

Yes, different requirements. Of the non-gcc compilers I've found so
far tcc looks most promising for being small and simple. Its object
code is far from optimised, though, (and is also in gas format).

yep.

 

[Seebs]

A few people have mentioned MinGW. The whole gcc thing is bulky but I
do like some of the code generation options it has such as pic, omit
frame pointer and various optimisations. I'd still rather define the
calling conventions myself but that's not something C programmers
typically want to do so is a bit off topic here.

You are not looking for C at all. You are looking for defining your own
ABI and using it on a bunch of systems.

Basically, you're Doing It Wrong. If you want to use C, *USE C*. Work
with the language the way it is designed, rather than trying to outsmart
it.

And that means that you don't waste valuable time and effort trying to
figure out ways to avoid recompiling on new targets, because *that is
silly*. The entire point of C is that you can *recompile* on new targets,
not that you can make magical binaries which are portable across unrelated
targets.

Then, all the "problems" go away. You don't care what compiler any given
target has as long as it supports the standard. You don't care what CPU
is in use, or anything like that. Poof! Problem solved by using the tool
for the purpose it was designed for.

-s

 

[jacob navia]

Le 12/11/11 17:02, James Harris a écrit :

I did say I wanted to generate object files.


Maybe but not for this application!

James

OK. I need much more information about what you want to do.

lcc is small and easy to port, and generates better code than other
similar compilers. This goes, however, beyond the topic of this
newsgroup, I am being flagged here as being too "commercial",and
a discussion about te commercial advantages of my product
would be unwelcome here.

My email is

jacob at jacob dot remcomp dot fr

Thanks for your interest in my work.

 

[jacob navia]

Le 13/11/11 10:10, Seebs a écrit :

You are not looking for C at all. You are looking for defining your own
ABI and using it on a bunch of systems.

Basically, you're Doing It Wrong. If you want to use C, *USE C*. Work
with the language the way it is designed, rather than trying to outsmart
it.

Sure, and you can't test for overflow in an efficient manner, you miss
all the speed of assembly language and you are limited by C limitations.

And a LONG etcetera. My customers need a code generator because what
they want to do is not C. If C would fit the bill they would use C.

 

[Ian Collins]

Le 13/11/11 10:10, Seebs a écrit :

Sure, and you can't test for overflow in an efficient manner, you miss
all the speed of assembly language and you are limited by C limitations.

The fact that you have customers looking for a code generator does prove
there is a demand. By surely the nice is small (all be profitable)?

On my usual platform (Solaris) the native compiler with all of it's
supporting paraphernalia will almost always generate faster applications
than hand optimising assembly language. I'm sure the same applies to
other hosted environments.

 

[jacob navia]

Le 13/11/11 11:03, Ian Collins a écrit :

On my usual platform (Solaris) the native compiler with all of it's
supporting paraphernalia will almost always generate faster applications
than hand optimising assembly language. I'm sure the same applies to
other hosted environments.

Just one example:

A 352 bit floating point. Yes, you can write that in C, but the speed
is very bad. Lcc-win's module is an order of magnitude faster. Why?

o Using add and add with carry to add 64 bit integers keeping the carry.
o Using many assembly specific instructions that the C compiler never
uses.
o And a long etcetera.

But I notice that you said:

"almost always"

Well...

 

[Nick Keighley]

You will find mostly negative answers about my work in this group.

only because you view any comment as some sort of criticism

 

[Seebs]

only because you view any comment as some sort of criticism

I had noticed a certain tendency towards that. I actually rather like some
of Jacob's ideas, but after a while I plonked him because it was too
frustrating trying to talk to him about them. My options were simpering
praise or being yelled at for my malicious and carefully planned campaign
of slander. Apparently, "being interested but having a suggestion for
an improvement" is not one of the available states.

-s

 

[jacob navia]

Le 13/11/11 04:13, Joe Wright a écrit :

Indeed.

"Indeed".

You fail to mention that mingw has a C99 compiler but a C80
Microsoft furnished library. This leads to some problems, as you may
have noticed.

lcc-win has essential parts of the C99 library like printf rewritten.
I do not use tha Microsoft printf, so at least the compiler is
coherent with the C library.