«

On Nov 13, 3:38*am, BGB <cr88...@hotmail.com> wrote:

....

> >> 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.
>
> 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

On 11/13/2011 1:00 AM, James Harris wrote:
> On Nov 13, 3:38 am, BGB<cr88...@hotmail.com> wrote:
>
> ...
>
>>>> 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.
>>
>> 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.)
>

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


>> 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.
>

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


>> 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.
>

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


>> 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).
>

yep.

On 2011-11-13, James Harris <> wrote:
> 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
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Le 12/11/11 17:02, James Harris a écrit :
> On Nov 12, 10:37 am, jacob navia<ja...@spamsink.net> wrote:
>> Le 12/11/11 11:09, James Harris a écrit :
>
> ...
>
>>>> 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.
>
> ...
>
>> 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

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.

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.

On 11/13/11 10:33 PM, jacob navia wrote:
> 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.

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.

--
Ian Collins

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...

On Nov 12, 9:36*am, jacob navia <ja...@spamsink.net> wrote:

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

only because you view any comment as some sort of criticism

On 2011-11-14, Nick Keighley <> wrote:
> On Nov 12, 9:36?am, jacob navia <ja...@spamsink.net> wrote:
>> You will find mostly negative answers about my work in this group.

> 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
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Le 13/11/11 04:13, Joe Wright a écrit :
> On 11/12/2011 21:59, Nobody wrote:
>> On Sat, 12 Nov 2011 01:22:45 -0800, James Harris wrote:
>>
>>> 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.
>>
> 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.