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]

On Nov 12, 9:36 am, jacob navia <ja...@spamsink.net> wrote:
> 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.

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 :

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]

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

[BGB]

granted, none of this will have much relevance to the OP.


yep, I have also done things along these lines (writing a JIT-based C
compiler).

the problems I ran into were mostly that my C compiler took too long (vs
a script language) due mostly to preprocessing/parsing headers (partly
optimized via caching, but still expensive to rebuild), and also that my
compiler and codegen were buggy, and I was sinking too much time into
trying to optimize and debug them.

this eventually ended up leading mostly to me shifting most of my
scripting/... effort back to my scripting language.


I had considered the possibility of a "C-like language" which would look
like C and be mostly compatible (albeit not strictly conformant), with
some alterations to allow it to be compiled much faster (it would treat
"#include" more as a module import, rather than actually inlining and
parsing the headers, as well as "reinterpreting" the declaration syntax).

however, I have not done much of anything with the idea yet.

granted, another (slightly less aggressive) strategy would be to use
precompiled headers. but, I guess one could get pedantic and debate
whether or not an implementation using precompiled headers is still "C"
as well.


but, sadly, I have more important things to do, and my scripting
language works plenty well enough (its C FFI is fairly decent).

probably, eventually my C compiler may just end up being moved to using
the same back-end as my scripting language anyways.


or such...

[Borax Man]

I would say GCC.

There is a DOS port called DJGPP.

There is a Windows port called MinGW which does not require Cygwin. I have
used MinGW under Windows XP without Cygwin installed. Works fine.


www.mingw.org

For assembler code, you can use the included assembler GAS, or if you prefer
(and I do too), NASM, which again, there are ports for DOS, Windows and
Unix.

GCC and optionally NASM will do all that you require.

[Nobody]

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.

[Joe Wright]

Indeed.

--
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."

[BGB]

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]

"James Harris" <james.h...@googlemail.com> wrote in message
news:d8ffed0a-4278-44a3...@p1g2000yqh.googlegroups.com...

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

"jacob navia" <ja...@spamsink.net> wrote in message
news:j9lem0$jrq$1...@speranza.aioe.org...

The song remains the same, huh jake.

[ankh]

Joe Wright wrote:
> 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.

RIP.

[James Harris]

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

[BGB]

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.

[Seebs]

On 2011-11-13, James Harris <james.h...@googlemail.com> 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...@seebs.net
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.

[jacob navia]

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

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]

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

[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]

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

[Seebs]

On 2011-11-14, Nick Keighley <nick_keigh...@hotmail.com> 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.

[Joe Wright]

On 11/14/2011 12:13, Seebs wrote:
> On 2011-11-14, Nick Keighley<nick_keigh...@hotmail.com> 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

Now don't you start. Peter Seebach has more creds in my book that Jacob
Navia will ever have. Relax. If we really want to see what a good
programmer can do starting with lcc, let's have a look at Pelle Orinius and
his PellesC.

[jacob navia]

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.

[jacob navia]

Le 13/11/11 05:43, ankh a écrit :

And you mean what by that sentence? What "song"? Who is "jake"?

[Ian Collins]

On 11/15/11 09:57 AM, jacob navia wrote:
>
> And you mean what by that sentence? What "song"? Who is "jake"?

Your troll filter needs retuning.

--
Ian Collins

[Nick Keighley]

On Nov 14, 5:13 pm, Seebs <usenet-nos...@seebs.net> wrote:

> On 2011-11-14, Nick Keighley <nick_keighley_nos...@hotmail.com> 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,

ditto. He has ideas that are worth discussing. If he were willing too.

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

you can't even have a technical difference of opinion, or suggest
there may be some other option without it being construed as a
personnel attack. Apparently I'm a moron for not agreeing whole-
heartedly with him.

[Nick Keighley]

On Nov 14, 8:55 pm, jacob navia <ja...@spamsink.net> wrote:
> 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.

long double?

[ImpalerCore]

Actually, I recently just blew away my MinGW and reinstalled
everything. In the latest version of GCC (4.6.1), the C99 printf
modifiers appear to work. Not sure what they changed, but it appears
that some workaround has been integrated into the MinGW toolchain.

Best regards,
John D.

[Keith Thompson]

ImpalerCore <jadi...@gmail.com> writes:
[...]

> Actually, I recently just blew away my MinGW and reinstalled
> everything. In the latest version of GCC (4.6.1), the C99 printf
> modifiers appear to work. Not sure what they changed, but it appears
> that some workaround has been integrated into the MinGW toolchain.

Interesting. I just did the same thing, and it still doesn't work
correctly.

Under Cygwin, this program:

#include <stdio.h>
int main(void) {
float f = 123.456;
double d = 123.456;
long double ld = 123.456;

printf("float: %d bytes, double: %d bytes, long double: %d bytes\n",
(int)sizeof (float),
(int)sizeof (double),
(int)sizeof (long double));
printf("f = %g\n", f);
printf("d = %g\n", d);
printf("ld = %Lg\n", ld);
return 0;
}

produces this (correct) output:

float: 4 bytes, double: 8 bytes, long double: 12 bytes
f = 123.456
d = 123.456
ld = 123.456

Under MinGW, installed from scratch on Windows 7 just a few minutes
ago,, with gcc 4.6.1, the same program produces this output:

float: 4 bytes, double: 8 bytes, long double: 12 bytes
f = 123.456
d = 123.456
ld = -6.41666e+264

Can you try this program on your system?

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacob navia]

Le 15/11/11 23:42, Keith Thompson a écrit :

>
> Under MinGW, installed from scratch on Windows 7 just a few minutes
> ago,, with gcc 4.6.1, the same program produces this output:
>
> float: 4 bytes, double: 8 bytes, long double: 12 bytes
> f = 123.456
> d = 123.456
> ld = -6.41666e+264
>
> Can you try this program on your system?
>

Try long long, it is bugged too.
That's why I rewrote printf from scratch.

And added all missing C99 functions lke the ones for setting
unsetting floating point precision, etc.

Years of work.

[ImpalerCore]

On Nov 15, 5:42 pm, Keith Thompson <ks...@mib.org> wrote:

I get the same result as you. It seems that their 'long double'
modifier is still broken. Still, I raised an eyebrow when %zu, %td,
%llu, and %lld started working.

\code
#include <stdio.h>
#include <limits.h>
#include <stdint.h>
#include <inttypes.h>

int main( void )
{
printf( "
------------------------------------------------------------------------
\n" );
printf( "| type | specifier | limit |
value |\n" );
printf( "
------------------------------------------------------------------------
\n" );

printf( " %-18s %-9s %-13s %" PRId8 "\n",
"int8_t", PRId8, "INT8_MIN", INT8_MIN );
printf( " %-18s %-9s %-13s %" PRId8 "\n",
"", "", "INT8_MAX", INT8_MAX );

printf( " %-18s %-9s %-13s %" PRId16 "\n",
"int16_t", PRId16, "INT16_MIN", INT16_MIN );
printf( " %-18s %-9s %-13s %" PRId16 "\n",
"", "", "INT16_MAX", INT16_MAX );

printf( " %-18s %-9s %-13s %" PRId32 "\n",
"int32_t", PRId32, "INT32_MIN", INT32_MIN );
printf( " %-18s %-9s %-13s %" PRId32 "\n",
"", "", "INT32_MAX", INT32_MAX );

#if defined(INT64_MIN)
printf( " %-18s %-9s %-13s %" PRId64 "\n",
"int64_t", PRId64, "INT64_MIN", INT64_MIN );
printf( " %-18s %-9s %-13s %" PRId64 "\n",
"", "", "INT64_MAX", INT64_MAX );
#endif

printf( " %-18s %-9s %-13s %" PRIu8 "\n",
"uint8_t", PRIu8, "UINT8_MAX", UINT8_MAX );
printf( " %-18s %-9s %-13s %" PRIu16 "\n",
"uint16_t", PRIu16, "UINT16_MAX", UINT16_MAX );
printf( " %-18s %-9s %-13s %" PRIu32 "\n",
"uint32_t", PRIu32, "UINT32_MAX", UINT32_MAX );
#if defined(UINT64_MAX)
printf( " %-18s %-9s %-13s %" PRIu64 "\n",
"uint64_t", PRIu64, "UINT64_MAX", UINT64_MAX );
#endif

printf( " %-18s %-9s %-13s %" PRIdMAX "\n",
"intmax_t", PRIdMAX, "INTMAX_MIN", INTMAX_MIN );
printf( " %-18s %-9s %-13s %" PRIdMAX "\n",
"", "", "INTMAX_MAX", INTMAX_MAX );
printf( " %-18s %-9s %-13s %" PRIuMAX "\n",
"uintmax_t", PRIuMAX, "UINTMAX_MAX", UINTMAX_MAX );

#if defined(LLONG_MAX)
printf( " %-18s %-9s %-13s %" "lld" "\n",
"long long", "lld", "LLONG_MIN", LLONG_MIN );
printf( " %-18s %-9s %-13s %" "lld" "\n",
"", "", "LLONG_MAX", LLONG_MAX );
printf( " %-18s %-9s %-13s %" "llu" "\n",
"unsigned long long", "llu", "ULLONG_MAX", ULLONG_MAX );
#endif

printf( " %-18s %-9s %-13s %zu\n",
"size_t", "zu", "SIZE_MAX", SIZE_MAX );
printf( " %-18s %-9s %-13s %td\n",
"ptrdiff_t", "td", "PTRDIFF_MIN", PTRDIFF_MIN );
printf( " %-18s %-9s %-13s %td\n",
"", "", "PTRDIFF_MAX", PTRDIFF_MAX );

return 0;
}
\endcode

Before, I would get incorrect results for zu, td, llu and lld. Now
they seem to be working.


------------------------------------------------------------------------
| type | specifier | limit |
value |

------------------------------------------------------------------------
int8_t d INT8_MIN -128
INT8_MAX 127
int16_t d INT16_MIN -32768
INT16_MAX 32767
int32_t d INT32_MIN -2147483648
INT32_MAX 2147483647
int64_t I64d INT64_MIN
-9223372036854775808
INT64_MAX 9223372036854775807
uint8_t u UINT8_MAX 255
uint16_t u UINT16_MAX 65535
uint32_t u UINT32_MAX 4294967295
uint64_t I64u UINT64_MAX
18446744073709551615
intmax_t I64d INTMAX_MIN
-9223372036854775808
INTMAX_MAX 9223372036854775807
uintmax_t I64u UINTMAX_MAX
18446744073709551615
long long lld LLONG_MIN
-9223372036854775808
LLONG_MAX 9223372036854775807
unsigned long long llu ULLONG_MAX
18446744073709551615
size_t zu SIZE_MAX 4294967295
ptrdiff_t td PTRDIFF_MIN -2147483648
PTRDIFF_MAX 2147483647

Best regards,
John D.

[Jo]

You are not good at what you want to do. You should change careers. You
are ineffectual and can't program yourself out of a paper bag (nor write
about it). Just a thought. Maybe some extrospection was in order, but you
can't seem to help yourself to save your own life or even leave a gleam
of it on this planet, so I thought I'd try to help you a bit.

[BartC]

"Jo" <no...@none.none> wrote in message
news:jaa1fn$2nj$1...@speranza.aioe.org...

> jacob navia wrote:

>> And you mean what by that sentence? What "song"? Who is "jake"?
>
> You are not good at what you want to do. You should change careers. You
> are ineffectual and can't program yourself out of a paper bag (nor write
> about it). Just a thought.

No. Someone writes some software with a million downloads, but of course
they are not good programmers! How many downloads do you have?

--
Bartc

[Fritz Wuehler]

"BartC" <b...@freeuk.com> wrote:

> No. Someone writes some software with a million downloads, but of course
> they are not good programmers! How many downloads do you have?

Good marketing = good programmer? What does the number of downloads have to
do with anything?

I hope your desktop is Windows and your phone is an iPhone.

I have navia killfiled but your statement is a ludicrous fallacy.

[Jo]

You said it just right Bart. About your "human virus" existence, that is.
Hello. What your mommie and daddie never told you, no could they, huh.
You want to be "liked" maybe. Did I make someone think? That's bad huh.
There is a quip on this board that goes something like: "make them think
they are <whatever>, you are golden. Make them think, they will hate
you". Something like that. Is it your turn to call me a narcissist? Bring
it, I dare you. I'm not calling you stupid, I just do that on the
internet. :P

[Jo]

Fritz Wuehler wrote:
> "BartC" <b...@freeuk.com> wrote:
>
>> No. Someone writes some software with a million downloads, but of
>> course they are not good programmers! How many downloads do you have?
>
> Good marketing = good programmer? What does the number of downloads
> have to do with anything?

That kind of thing annoys me totally. That anyone would think that anyone
else would be so fucking stupid as to fall for well-known bullshit. THIS,
really irks me. Makes me mad as hell. (Not that I am religious or suggest
that some fucking stupid concept like that could be mad..... pfft).

>
> I hope your desktop is Windows and your phone is an iPhone.

I know you were tallking to him (Jake, not you as "him", you creep), but
mine is. It causes me to get really drunk and lament here. Yes, Windows
is like, well, it's not "like" that at all... Windows is my own and
personal, "wheel of pain". And you fucking know it.

>
> I have navia killfiled but your statement is a ludicrous fallacy.

You shouldn't "bozo bin" anyone ever probably, unless they become
bot-ish. IMO. I made no statement. I was just poking fun at him. He knows
he can't hang. He doesn't need you to tell me that he can't, which you
did. (I am soooo bad!!!!).

[Brian]

Sorry, but this is factually wrong.

Navia did not write the software. He bought the source code to lcc and
the rights to exploit it commercially.

He has added almost nothing of value to it: only an ugly GUI and a few
non-standard proprietary language additions that are useless to anyone
who wants to write portable code.

[James Kuyper]

On 11/22/2011 11:47 AM, Brian wrote:
...

> Navia did not write the software. He bought the source code to lcc and
> the rights to exploit it commercially.
>
> He has added almost nothing of value to it: only an ugly GUI and a few
> non-standard proprietary language additions that are useless to anyone
> who wants to write portable code.

But there's apparently a lot of people who don't care about portable
code, and who like his non-standard additions a lot better than you or I
would.

Are his extensions proprietary? He's frequently recommended that they be
standardized. I'm not a lawyer, but it seems to me that if they are
indeed proprietary, he would have to hand over the intellectual property
rights to ISO in order for ISO to be able to incorporate them into a
future standard.

[Richard Sanders]

On Tue, 22 Nov 2011 16:47:02 +0000 (UTC), Brian <nos...@nospam.com>
wrote:

>Navia did not write the software. He bought the source code to lcc and
>the rights to exploit it commercially.

https://github.com/drh/lcc/blob/master/CPYRIGHT

>He has added almost nothing of value to it: only an ugly GUI and a few
>non-standard proprietary language additions that are useless to anyone
>who wants to write portable code.

I was happy with LCC-Win until I started to use FLTK that requires
C++. I found the IDE to be clean without a whole bunch of (dockable)
windows reducing screen realestate. I wish MinGw compiled as fast as
LCC-Win.

As for "proprietary language additions". You are not compelled to use
these non portable additions, they are purly optional.

[jacob navia]

Le 22/11/11 17:47, Brian a écrit :

rry, but this is factually wrong.
>
> Navia did not write the software. He bought the source code to lcc and
> the rights to exploit it commercially.
>

This is not true.

I have written for the compiler:

o The optimizer (Code of lcc-win is faster than plain lcc)
o New types supported like long double and long long.
o Ported the code generator to the new CPUs. XMM extensions of
the x86 CPU.
o Countless fixes and improvements during years of work.
o The assembler. Plain lcc generates ascii. Lcc-win writes object files.
o The linker. Plain lcc has no linker.
o The IDE.
o The debugger.
o The resource editor.
o The make and project handling utility.

> He has added almost nothing of value to it: only an ugly GUI and a few
> non-standard proprietary language additions that are useless to anyone
> who wants to write portable code.

lcc-win is C99. I wrote all necessary modifications to the compiler and
I wrote entirely the C99 C library.

But for these people, no lie will be enough.

[jacob navia]

Le 22/11/11 18:10, James Kuyper a écrit :

> On 11/22/2011 11:47 AM, Brian wrote:
> ...
>> Navia did not write the software. He bought the source code to lcc and
>> the rights to exploit it commercially.
>>
>> He has added almost nothing of value to it: only an ugly GUI and a few
>> non-standard proprietary language additions that are useless to anyone
>> who wants to write portable code.
>
> But there's apparently a lot of people who don't care about portable
> code, and who like his non-standard additions a lot better than you or I
> would.
>

Specially people that like 120 digits precision floats that can be used
with the same easy than normal doubles in C. Lcc-win has many
engineering applications.

The JIT compiler is popular among software that generates C.

> Are his extensions proprietary?

No.

> He's frequently recommended that they be
> standardized.

Yes. That would be stupid if they were propietary...

> I'm not a lawyer, but it seems to me that if they are
> indeed proprietary, he would have to hand over the intellectual property
> rights to ISO in order for ISO to be able to incorporate them into a
> future standard.

My extensions can be copyrighted as propietary. Please, not everyone
here has this american habit of software patents (Amazon patented
the "one click" button... Apple patented the desktop, whatever). I
haven't any patent pending.

And you know that Mr Kuyper.

[Friedrich Dominicus]

Brian <nos...@nospam.com> writes:

>
> He has added almost nothing of value to it: only an ugly GUI and a few
> non-standard proprietary language additions that are useless to anyone
> who wants to write portable code.

You have not the slightest idea, but well you're not alone with that.


--
Please remove just-for-news- to reply via e-mail.

[Malcolm McLean]

On Nov 23, 7:28 am, Friedrich Dominicus <just-for-news-fr...@q-

software-solutions.de> wrote:
> Brian <nos...@nospam.com> writes:
>
> > He has added almost nothing of value to it: only an ugly GUI and a few
> > non-standard proprietary language additions that are useless to anyone
> > who wants to write portable code.
>
> You have  not the slightest idea, but well you're not  alone with that.
>

Not all code has to be portable. If you add something of value to a C
compiler, really you have to add a non-standard feature. Otherwise
your compiler isn't much different from anyone else's and there's no
reason to choose it.

It seems that Jacob will be criticised either way.

--
NEW!!!! Sequence logo code
http://www.malcolmmclean.site11.com/www

[Willem]

Malcolm McLean wrote:
) On Nov 23, 7:28?am, Friedrich Dominicus <just-for-news-fr...@q-
) software-solutions.de> wrote:
)> Brian <nos...@nospam.com> writes:
)>
)> > He has added almost nothing of value to it: only an ugly GUI and a few
)> > non-standard proprietary language additions that are useless to anyone
)> > who wants to write portable code.
)>
)> You have ?not the slightest idea, but well you're not ?alone with that.
)>
) Not all code has to be portable. If you add something of value to a C
) compiler, really you have to add a non-standard feature. Otherwise
) your compiler isn't much different from anyone else's and there's no
) reason to choose it.

Well, you can compete in optimization, and you can also upgrade to a new
standard. C99, in this case. Oh, and a slick IDE is a selling point as
well.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[BartC]

"Brian" <nos...@nospam.com> wrote in message
news:jagjm6$q6b$1...@speranza.aioe.org...

Well, the original LCC compiler is still available for download. Although
you will require an existing C compiler, and the know-how to be able to
build binaries for your platform. And, the time needed to write, acquire, or
modify various extras that lcc-win already provides (such as windows.h
perhaps).

It all sounds so straightforward! You wonder why someone doesn't spend an
hour or so doing this and provide binaries for people to use out-of-the-box.

In fact, Pelles C is also based on LCC! And this product is generally
well-regarded. It probably took rather more than an hour however.

--
Bartc

[jacob navia]

Le 22/11/11 20:13, jacob navia a écrit :

Well, apparently "jo" and "Brian" kept silent. Until next time when
they will repeat their attacks, their lies, etc.

That is why I get so paranoiac... Years of this anonymous attacks can
transform someone into maybe someone else.

Easy to do for anonymous cowards like those.

[Nick Keighley]

On Nov 22, 4:47 pm, Brian <nos...@nospam.com> wrote:
> On Sun, 20 Nov 2011 12:58:29 +0000, BartC wrote:

> > "Jo" <n...@none.none> wrote in message

> >news:jaa1fn$2nj$1...@speranza.aioe.org...
> >> jacob navia wrote:
>
> >>> And you mean what by that sentence? What "song"? Who is "jake"?
>
> >> You are not good at what you want to do. You should change careers. You
> >> are ineffectual and can't program yourself out of a paper bag (nor
> >> write about it). Just a thought.
>
> > No. Someone writes some software with a million downloads, but of course
> > they are not good programmers! How many downloads do you have?
>
> Sorry, but this is factually wrong.
>
> Navia did not write the software. He bought the source code to lcc and
> the rights to exploit it commercially.
>
> He has added almost nothing of value to it:

I'm pretty sure this is untrue. He's added a wide variety of
extensions and support tools. I'm pretty sure the debugger and
assembler or entirely his. A debugger is *very* non-trivial. The C99
featurs are his too.

> only an ugly GUI and a few
> non-standard proprietary language additions that are useless to anyone
> who wants to write portable code.

Not everyone does.

[Nick Keighley]

after all gcc is crawling with bizzare extensions

[Malcolm McLean]

On Nov 23, 12:57 pm, Willem <wil...@toad.stack.nl> wrote:
>
> Well, you can compete in optimization, and you can also upgrade to a new
> standard.  C99, in this case.  Oh, and a slick IDE is a selling point as
> well.
>

Optimisation is a bit one-dimensional. If you have the most optimal
compiler on the market, you have a unique selling point. But that's
hard to achieve, and you'll likely lose the selling point as the
competition catches up. A better strategy is to segment the
marketplace, e.g. target people who want garbage collection.

There doesn't seem to be much demand for C99. It's a failed standard.
--
Basic Algorithms: a massive compendium of C programming resources
http://www.malcolmmclean.site11.com/www

[James Harris]

On Nov 13, 9:10 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2011-11-13, James Harris <james.harri...@googlemail.com> 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.

Your comments are 'robust'. I will return the compliment. :-)

You are being naive, Peter. If C is the best tool for the job it makes
sense to use it. Period. There is no point ignoring C for this task
because it is not perfect. Nothing is. C is by far the best HLL I know
of for what I want to do so it makes sense to use it.

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

For just about all the C programming I have ever done I have had to
interface with no other programming languages. In this project that is
not the case. The C code will have to work with code written in other
languages, if only assembler.

As things stand I will have to adjust the asm to dovetail with one of
the calling conventions of the C compiler I choose. I would *prefer*
the option to customise the compiler's output to conventions that I
select - but I recognise that may not be possible.

Taking a step back, consider a C anomaly. Look at how low-level C is
and why it is favoured as a 'portable assembler' (not a phrase I am
recommending) by compiler writers and others. In C there is usually a
clear, direct and simple correspondence between C operations and a
CPU's opcodes, and a similar correspondence between C data types and
those supported by the CPU.

However, this simple one-to-one mapping of C features to CPU features
does not apply to subroutine calls and function prologues and
epilogues. In this case (like no other in the language?) C generates a
slew of instructions for one source language construct. I understand
why and agree with the choice. C was meant to interface with C.
However, it is a distinct difference in the level of the language. I
was commenting on the lack of control over this part of the object
code.

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

You misunderstand. I was not talking about avoiding recompilation. I
was talking, in part, about interfacing C with non-C.

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

This is true for most C programming but if you are saying this is
universally true I don't agree. In my case the OS has distinct address
space, tasking and resource models. This is the other part of what I
was talking about: interfacing C with the desired OS models. So I *do*
care what the compiler generates. It matters to the goals of the
project.

James

[Ian Collins]

On 12/11/11 08:29 AM, James Harris wrote:
> On Nov 13, 9:10 am, Seebs<usenet-nos...@seebs.net> wrote:
>
> For just about all the C programming I have ever done I have had to
> interface with no other programming languages. In this project that is
> not the case. The C code will have to work with code written in other
> languages, if only assembler.
>
> As things stand I will have to adjust the asm to dovetail with one of
> the calling conventions of the C compiler I choose. I would *prefer*
> the option to customise the compiler's output to conventions that I
> select - but I recognise that may not be possible.

You haven't really said what you are trying to do. Are you targeting a
hosted platform? If so the function call ABI will already be well defined.

> Taking a step back, consider a C anomaly. Look at how low-level C is
> and why it is favoured as a 'portable assembler' (not a phrase I am
> recommending) by compiler writers and others. In C there is usually a
> clear, direct and simple correspondence between C operations and a
> CPU's opcodes, and a similar correspondence between C data types and
> those supported by the CPU.

Once upon a time long ago, maybe. This certainly isn't the case today.

> However, this simple one-to-one mapping of C features to CPU features
> does not apply to subroutine calls and function prologues and
> epilogues. In this case (like no other in the language?) C generates a
> slew of instructions for one source language construct. I understand
> why and agree with the choice. C was meant to interface with C.
> However, it is a distinct difference in the level of the language. I
> was commenting on the lack of control over this part of the object
> code.

The "lack of control" is because the function call ABI is defined for
the platform/CPU outside of the C standard. To invent some arbitrary
ABI that does not conform with the host is pointless.

>> 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.
>
> You misunderstand. I was not talking about avoiding recompilation. I
> was talking, in part, about interfacing C with non-C.

Which is often define in the "non C" language specification.

>> 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.
>
> This is true for most C programming but if you are saying this is
> universally true I don't agree. In my case the OS has distinct address
> space, tasking and resource models. This is the other part of what I
> was talking about: interfacing C with the desired OS models. So I *do*
> care what the compiler generates. It matters to the goals of the
> project.

So you you are using an OS without a well defined ABI?

--
Ian Collins

[Seebs]

On 2011-12-10, James Harris <james.h...@googlemail.com> wrote:
> You are being naive, Peter. If C is the best tool for the job it makes
> sense to use it. Period. There is no point ignoring C for this task
> because it is not perfect. Nothing is. C is by far the best HLL I know
> of for what I want to do so it makes sense to use it.

If you want to use it, then use it!

Your theory here is roughly equivalent to pounding screws in with a hammer
becasue the hammer is the best tool you know of.

> As things stand I will have to adjust the asm to dovetail with one of
> the calling conventions of the C compiler I choose. I would *prefer*
> the option to customise the compiler's output to conventions that I
> select - but I recognise that may not be possible.

Probably the best solution would be to use inline assembly, which most
compilers can integrate nicely.

It seems to me like the impression I got was not correct. My understanding
was that you wanted to compile C, once, to a binary form and then use those
binaries unmodified on a variety of systems. This is the Wrong Way To Do It.

If you need to interact with assembly, the usual way to do it is to use
either compiler-specific inline assembly things, or system-specific hunks of
glue.

It'd probably be easier to give better advice with a clearer and higher-level
idea of what you're trying to do.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet...@seebs.net
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.

[James Harris]

On Dec 10, 8:57 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 12/11/11 08:29 AM, James Harris wrote:

...

> You haven't really said what you are trying to do.  Are you targeting a
> hosted platform?  If so the function call ABI will already be well defined.

I did say (in the title/subject) that this is for development of an OS
- an operating system. As such, no, this is not for a hosted platform.
The 'platform' itself is being defined, as is the ABI.

> > Taking a step back, consider a C anomaly. Look at how low-level C is
> > and why it is favoured as a 'portable assembler' (not a phrase I am
> > recommending) by compiler writers and others. In C there is usually a
> > clear, direct and simple correspondence between C operations and a
> > CPU's opcodes, and a similar correspondence between C data types and
> > those supported by the CPU.
>
> Once upon a time long ago, maybe.  This certainly isn't the case today.

I don't understand but am interested in the idea. What has changed to
make this no longer the case?

> > However, this simple one-to-one mapping of C features to CPU features
> > does not apply to subroutine calls and function prologues and
> > epilogues. In this case (like no other in the language?) C generates a
> > slew of instructions for one source language construct. I understand
> > why and agree with the choice. C was meant to interface with C.
> > However, it is a distinct difference in the level of the language. I
> > was commenting on the lack of control over this part of the object
> > code.
>
> The "lack of control" is because the function call ABI is defined for
> the platform/CPU outside of the C standard.  To invent some arbitrary
> ABI that does not conform with the host is pointless.

As the OS is new there is no host software at all. The OS's use of the
CPU is fairly generic and could apply to various processors. So all of
the structure and interface is up for definition.

...

> > In my case the OS has distinct address
> > space, tasking and resource models. This is the other part of what I
> > was talking about: interfacing C with the desired OS models. So I *do*
> > care what the compiler generates. It matters to the goals of the
> > project.
>
> So you you are using an OS without a well defined ABI?

Well, the interface to the OS will be well defined but the design is
intended to be based on first principles and, as far as possible, to
avoid influence from existing systems.

Sorry to be vague about the OS internals. They are well off-topic for
c.l.c.

James

[Ian Collins]

On 12/11/11 11:26 AM, James Harris wrote:
> On Dec 10, 8:57 pm, Ian Collins<ian-n...@hotmail.com> wrote:
>> On 12/11/11 08:29 AM, James Harris wrote:
>

> ....

>
>> You haven't really said what you are trying to do. Are you targeting a
>> hosted platform? If so the function call ABI will already be well defined.
>
> I did say (in the title/subject) that this is for development of an OS
> - an operating system. As such, no, this is not for a hosted platform.
> The 'platform' itself is being defined, as is the ABI.

Well that clarifies things. You would still be well advised to follow
existing practice for your ABI. If nothing else, that will simplify
writing a gcc port for your platform. For some processors (AMD64,
Sparc) calling conventions are well defined.

>>> Taking a step back, consider a C anomaly. Look at how low-level C is
>>> and why it is favoured as a 'portable assembler' (not a phrase I am
>>> recommending) by compiler writers and others. In C there is usually a
>>> clear, direct and simple correspondence between C operations and a
>>> CPU's opcodes, and a similar correspondence between C data types and
>>> those supported by the CPU.
>>
>> Once upon a time long ago, maybe. This certainly isn't the case today.
>
> I don't understand but am interested in the idea. What has changed to
> make this no longer the case?

Optimisation technology.

--
Ian Collins

[James Harris]

On Dec 10, 9:13 pm, Seebs <usenet-nos...@seebs.net> wrote:

> On 2011-12-10, James Harris <james.harri...@googlemail.com> wrote:
>
> > You are being naive, Peter. If C is the best tool for the job it makes
> > sense to use it. Period. There is no point ignoring C for this task
> > because it is not perfect. Nothing is. C is by far the best HLL I know
> > of for what I want to do so it makes sense to use it.
>
> If you want to use it, then use it!
>
> Your theory here is roughly equivalent to pounding screws in with a hammer
> becasue the hammer is the best tool you know of.

Analogies paint mental images but are not necessarily apt. In fact C
is a better fit than your analogy suggests - but it's not perfect.
Why? In this case perhaps it's like a screwdriver that doesn't just
drive in screws - i.e. it doesn't just do at the assembler level what
it's been told in the HLL. It does a relatively complex subroutine
linkage too.

When you think about it there's quite a lot of choices that a C
compiler takes on itself when calling subroutines: how to pass
parameters, which should be caller- and callee-save registers, how to
locate the target and how to return results. Pretty much none of these
fit my current plan!

> > As things stand I will have to adjust the asm to dovetail with one of
> > the calling conventions of the C compiler I choose. I would *prefer*
> > the option to customise the compiler's output to conventions that I
> > select - but I recognise that may not be possible.
>
> Probably the best solution would be to use inline assembly, which most
> compilers can integrate nicely.

I understand the suggestion and can see its sense but it doesn't work
for me for two reasons: 1) inline asm is awful to work with compared
with my preferred assembler, Nasm and 2) such a course wouldn't remove
the subroutine linkage that is the cause of the problem. Interfacing
with another language is just one part of the requirement. The other
is implementing a specific form of interface between the modules that
make up the OS. No language I know of other than assembler allows
these things to be defined.

> It seems to me like the impression I got was not correct.  My understanding
> was that you wanted to compile C, once, to a binary form and then use those
> binaries unmodified on a variety of systems.  This is the Wrong Way To Do It.

Right. That is not the intention.

> If you need to interact with assembly, the usual way to do it is to use
> either compiler-specific inline assembly things, or system-specific hunks of
> glue.

Agreed. I have plans to develop the system itself as pure as possible
and later provide glue code to interface with more traditional
systems.

> It'd probably be easier to give better advice with a clearer and higher-level
> idea of what you're trying to do.

Thanks for taking an interest but my plans are well off topic for this
newsgroup and are still being formed so I won't bore people here with
them.

I have an answer to the original question: despite some negatives such
as its size gcc appears to be the closest fit to what I was looking
for. However, I have found that trying to work with it tends to
constrain the design. I keep finding I am making the design fit the
compiler. So for the time being I am sticking with assembler. Once the
design is stable I will look at interfacing to HLLs and compilers.

James

[Seebs]

On 2011-12-10, James Harris <james.h...@googlemail.com> wrote:

> I did say (in the title/subject) that this is for development of an OS
> - an operating system. As such, no, this is not for a hosted platform.
> The 'platform' itself is being defined, as is the ABI.

I would point out that ABIs are often defined by the architecture in some
way. There is a "MIPS ABI" (well, there's several) which exists independent
of your choice of operating system.

>> > Taking a step back, consider a C anomaly. Look at how low-level C is
>> > and why it is favoured as a 'portable assembler' (not a phrase I am
>> > recommending) by compiler writers and others. In C there is usually a
>> > clear, direct and simple correspondence between C operations and a
>> > CPU's opcodes, and a similar correspondence between C data types and
>> > those supported by the CPU.

>> Once upon a time long ago, maybe. ?This certainly isn't the case today.

> I don't understand but am interested in the idea. What has changed to
> make this no longer the case?

Well, strictly speaking, it never was. Consider:

long a, b, c;
a = get_a_number();
b = get_a_number();
c = a * b;

I'm pretty sure this has been implemented in software on at least some C
implementations since the 70s, because there have been 32-bit longs on 16-bit
systems.

Similarly, 64-bit values on 32-bit systems, floating point math on machines
with no FPU... The list goes on, and on, and on.

C hasn't really been much for 1:1 correspondences in a very long time. I
think the most obvious cutoff, if you wanted one, would be struct assignment.

> As the OS is new there is no host software at all. The OS's use of the
> CPU is fairly generic and could apply to various processors. So all of
> the structure and interface is up for definition.

If you don't use a standard ABI for each CPU, you will have a much harder
time.

> Well, the interface to the OS will be well defined but the design is
> intended to be based on first principles and, as far as possible, to
> avoid influence from existing systems.

I think C is the wrong tool for this, then, as a great deal of the benefit of
C is a mature ecosystem for using standard ABIs.

[Seebs]

On 2011-12-10, James Harris <james.h...@googlemail.com> wrote:

> Analogies paint mental images but are not necessarily apt. In fact C
> is a better fit than your analogy suggests - but it's not perfect.
> Why? In this case perhaps it's like a screwdriver that doesn't just
> drive in screws - i.e. it doesn't just do at the assembler level what
> it's been told in the HLL. It does a relatively complex subroutine
> linkage too.

Well, yes. That's necessary for it to do its job.

> When you think about it there's quite a lot of choices that a C
> compiler takes on itself when calling subroutines: how to pass
> parameters, which should be caller- and callee-save registers, how to
> locate the target and how to return results. Pretty much none of these
> fit my current plan!

Then C is probably the wrong tool, because the entire *point* of C is to
Make That Go Away. This is supposed to be a language you can use in
complete ignorance of whether your target system even *has* registers,
let alone how many, what sizes, or what rules they follow. If you need
to think about things like that, you need a different category of tool.

> I understand the suggestion and can see its sense but it doesn't work
> for me for two reasons: 1) inline asm is awful to work with compared
> with my preferred assembler, Nasm and 2) such a course wouldn't remove
> the subroutine linkage that is the cause of the problem. Interfacing
> with another language is just one part of the requirement. The other
> is implementing a specific form of interface between the modules that
> make up the OS. No language I know of other than assembler allows
> these things to be defined.

Ayup. That's because it's not even coherent to speak of defining them
outside of an absolute commitment to a specific CPU.

... BTW, I should point out, even though I don't currently think this will
work out as you've described it, it's been a nice change disagreeing with
someone who appears to be basically lucid. I'm sorry if I come across as
harsh; I don't think what you're doing is stupid or crazy, I just think it's
probably not going to turn out to be a good fit for C unless you feel like
developing your own compiler for it.

[James Harris]

On Dec 10, 10:38 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 12/11/11 11:26 AM, James Harris wrote:
>
> > On Dec 10, 8:57 pm, Ian Collins<ian-n...@hotmail.com>  wrote:
> >> On 12/11/11 08:29 AM, James Harris wrote:
>
> > ....
>
> >> You haven't really said what you are trying to do.  Are you targeting a
> >> hosted platform?  If so the function call ABI will already be well defined.
>
> > I did say (in the title/subject) that this is for development of an OS
> > - an operating system. As such, no, this is not for a hosted platform.
> > The 'platform' itself is being defined, as is the ABI.
>
> Well that clarifies things.

Great.

> You would still be well advised to follow
> existing practice for your ABI.  If nothing else, that will simplify
> writing a gcc port for your platform.

I understand the point. However, from what I have done so far I can
see it would be easy to miss useful innovations by being influenced by
existing systems. The whole point of writing a new OS is to do things
in a new way. So my intention is as far as possible to make a clean
design and then to provide interfacing as needed.

If I can wax lyrical for a moment: How often does a programmer get to
write something that is totally independent of existing systems?
Almost never. We work with specific operating systems such as Unix,
Windows, DOS etc. We work with specific libraries such as sockets and
various GUIs and we work with specific file formats such as Elf, jpeg
etc. And we work with specific concepts such as files and data
streams. *All* of these are up for grabs when writing an OS.

If anyone is interested in looking at this there is some info at

http://aodfaq.wikispaces.com/

put together by a bunch of people doing similar.

> For some processors (AMD64,
> Sparc) calling conventions are well defined.


> >>> Taking a step back, consider a C anomaly. Look at how low-level C is
> >>> and why it is favoured as a 'portable assembler' (not a phrase I am
> >>> recommending) by compiler writers and others. In C there is usually a
> >>> clear, direct and simple correspondence between C operations and a
> >>> CPU's opcodes, and a similar correspondence between C data types and
> >>> those supported by the CPU.
>
> >> Once upon a time long ago, maybe.  This certainly isn't the case today.
>
> > I don't understand but am interested in the idea. What has changed to
> > make this no longer the case?
>
> Optimisation technology.

I don't see this. I was talking about how C operations are those you
will find on a CPU's ALU: arithmetic, shifts, bitwise operations; and
how C's data types map to typical CPU data types: signed and unsigned
integers and bitfields of different widths, floats of differing types.
Surely these are not dependent on optimisation.

James

[Ian Collins]

On 12/11/11 01:01 PM, James Harris wrote:
> On Dec 10, 10:38 pm, Ian Collins<ian-n...@hotmail.com> wrote:
>> On 12/11/11 11:26 AM, James Harris wrote:
>
>> You would still be well advised to follow
>> existing practice for your ABI. If nothing else, that will simplify
>> writing a gcc port for your platform.
>
> I understand the point. However, from what I have done so far I can
> see it would be easy to miss useful innovations by being influenced by
> existing systems. The whole point of writing a new OS is to do things
> in a new way. So my intention is as far as possible to make a clean
> design and then to provide interfacing as needed.

Consider this: why would the designers of an OS ABI choose an
inefficient calling convention?

> If I can wax lyrical for a moment: How often does a programmer get to
> write something that is totally independent of existing systems?
> Almost never. We work with specific operating systems such as Unix,
> Windows, DOS etc. We work with specific libraries such as sockets and
> various GUIs and we work with specific file formats such as Elf, jpeg
> etc. And we work with specific concepts such as files and data
> streams. *All* of these are up for grabs when writing an OS.

They are also frequently up for grabs in embedded systems, where most C
programmers operate these days.

>>> I don't understand but am interested in the idea. What has changed to
>>> make this no longer the case?
>>
>> Optimisation technology.
>
> I don't see this. I was talking about how C operations are those you
> will find on a CPU's ALU: arithmetic, shifts, bitwise operations; and
> how C's data types map to typical CPU data types: signed and unsigned
> integers and bitfields of different widths, floats of differing types.
> Surely these are not dependent on optimisation.

You could say the same for any programming language. C does allow you
to specify exact with types, but they are provided to enable C to
interface with low level entities. Most C programs won't use them.

How an instance of a type is manipulated is very much dependent on
optimisation. A declared variable may not even exist in optimised code.
The machine instructions emitted by an optimising compiler often bear
little resemblance to the code written by the programmer. Functions get
inlined, instructions get reordered and so on.

--
Ian Collins

[jacob navia]

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

>
> I have an answer to the original question: despite some negatives such
> as its size gcc appears to be the closest fit to what I was looking
> for. However, I have found that trying to work with it tends to
> constrain the design. I keep finding I am making the design fit the
> compiler. So for the time being I am sticking with assembler. Once the
> design is stable I will look at interfacing to HLLs and compilers.

Gcc is too big for what you want. You need a compiler that you can
possibly understand or have someone that can help you out with a
question, etc.

There are (maybe) 10-20 people in the world that have a very detailed
knowledge of gcc in all its complexity.


Once I needed to interface my code with gcc, and needed to know
how the exception handling is implemented in gcc, specially in
C++/Linux.

It took me 5-6 MONTHS.

o Wrong documentation or inexsiting documentation. I used the
specs of the ABI only to find out that gcc doesn't implement
all of it and "enhances" most of the implementation. When
asking questions I always got the same answer:

You have the source!

Huge files implement that part, without a single comment in them
besides the GNU copyright stuff. Yes; just understand something
in there.

o I asked the guy that knew the stuff (working at RedHat). He told
me I would have to buy a RedHat maintenance contract for support
for a year: US$ 25,000.

o Bad design. For instance, you write in the assembler
.byte 0x38
and expect (naively) that the corresponding value will
appear in the object file. No, it doesn't.

When I filed a bug report, they told me that for certain
sections, the assembler "optimizes" the writing of the
values and ignores some. Great.

o There is NO WAY you will be able to understand gcc enough
to make any modifications to it unless you spend several
years working. You understimate badly the problem.

I tried to fix a bug, some time ago. Floating point stdcall
functions under windows would crash... bad code was generated.

I worked for 2 weeks before giving up. Try understanding their
"RTL" then the different structures and hacks, etc. You will
get nowhere, and you will never be able to modify anything.

You can verify this. Just TRY to modify a minimal thing.



Of course I am biased. But you will be able to verify all I am saying.
Just try to make a trivial modification within gcc, say for instance
you want to use in your os always a stdcall calling convention and
instead of returning with

ret

you always

ret $n

where n is the number of words in the stack pushed by the caller.

Have fun!

jacob

[Seebs]

On 2011-12-11, James Harris <james.h...@googlemail.com> wrote:
> I understand the point. However, from what I have done so far I can
> see it would be easy to miss useful innovations by being influenced by
> existing systems. The whole point of writing a new OS is to do things
> in a new way. So my intention is as far as possible to make a clean
> design and then to provide interfacing as needed.

Hmm. Well, it's an interesting experiment, anyway. I'm not sure I'd expect
it to yield significant advantages.

> If I can wax lyrical for a moment: How often does a programmer get to
> write something that is totally independent of existing systems?
> Almost never.

I have rarely *wanted* to. Interactions with stuff is what makes things
interesting.

> I don't see this. I was talking about how C operations are those you
> will find on a CPU's ALU: arithmetic, shifts, bitwise operations; and
> how C's data types map to typical CPU data types: signed and unsigned
> integers and bitfields of different widths, floats of differing types.
> Surely these are not dependent on optimisation.

For an obvious example that someone recently brought up: Many ARM processors
lack a divider in hardware.

So there's often, for even the most primitive operations, substantial code
generation going on behind the scenes.

[Robert Wessel]

On Sun, 11 Dec 2011 13:18:09 +1300, Ian Collins <ian-...@hotmail.com>
wrote:

>On 12/11/11 01:01 PM, James Harris wrote:
>> On Dec 10, 10:38 pm, Ian Collins<ian-n...@hotmail.com> wrote:
>>> On 12/11/11 11:26 AM, James Harris wrote:
>>
>>> You would still be well advised to follow
>>> existing practice for your ABI. If nothing else, that will simplify
>>> writing a gcc port for your platform.
>>
>> I understand the point. However, from what I have done so far I can
>> see it would be easy to miss useful innovations by being influenced by
>> existing systems. The whole point of writing a new OS is to do things
>> in a new way. So my intention is as far as possible to make a clean
>> design and then to provide interfacing as needed.
>
>Consider this: why would the designers of an OS ABI choose an
>inefficient calling convention?

Good question, but it happens. Both native S/360 and VAX OSs picked
painfully expensive ABIs out of some attempt at generality, VAX being
even worse, *and* partially fixed in hardware. Part of it was
certainly an expectation that system (and subroutine) calls would be
fairly rare, these being designed in the era of monolithic programs.
On both systems compilers would often use a different (and much
lighter weight) ABI within a program, and switch to the system ABI
between modules.

And the AS/400, which largely required an entire context switch
between separately compiled programs, made both of those look
positively featherweight by comparison (although that's been fixed in
later versions). Again, there was an assumption of monolithic
programs.

Certainly more recent systems have made lighter weight calling
conventions much more of a priority. Even in those cases, ABI have
tended to be pretty sticky, and unable to take advantage of ISA
changes (consider FP calling conventions on x86-32, which really don't
make sense, except in terms of backwards compatibility, in the
presence of SSE2).

[James Kuyper]

On 12/10/2011 02:29 PM, James Harris wrote:
...
> ... In C there is usually a

> clear, direct and simple correspondence between C operations and a
> CPU's opcodes, and a similar correspondence between C data types and
> those supported by the CPU.

Not all machines had opcodes that match every C operations, and not all
C operations have corresponding single opcodes on every machine. Many
operations have long been emulated on some machines rather than being
directly supported; such as 32-bit integers on 8-bit machines, or 8-bit
types on 32-bit machines, or floating point operations on machines with
no FPU.

Also, optimization has always rendered the relationship less than
perfectly "clear, direct, and simple". Compare the assembly code
generated by the highest optimization level for a typical compiler with
your original C code; if the relationship is at all "clear, direct, and
simple", it's probably a compiler whose optimization capabilities are
substantially inferior to the current state of the art.
--
James Kuyper

[88888 Dihedral]

Yes, there was an European software company bought by the British arm company.
I thought that was a good move to kill obsolete 8051-8052 by the 32 bit arm.

[James Harris]

On Dec 11, 12:18 am, Ian Collins <ian-n...@hotmail.com> wrote:
> On 12/11/11 01:01 PM, James Harris wrote:
>
> > On Dec 10, 10:38 pm, Ian Collins<ian-n...@hotmail.com>  wrote:
> >> On 12/11/11 11:26 AM, James Harris wrote:
>
> >> You would still be well advised to follow
> >> existing practice for your ABI.  If nothing else, that will simplify
> >> writing a gcc port for your platform.
>
> > I understand the point. However, from what I have done so far I can
> > see it would be easy to miss useful innovations by being influenced by
> > existing systems. The whole point of writing a new OS is to do things
> > in a new way. So my intention is as far as possible to make a clean
> > design and then to provide interfacing as needed.
>
> Consider this: why would the designers of an OS ABI choose an
> inefficient calling convention?

There is far more to this than an ABI!

> > If I can wax lyrical for a moment: How often does a programmer get to
> > write something that is totally independent of existing systems?
> > Almost never. We work with specific operating systems such as Unix,
> > Windows, DOS etc. We work with specific libraries such as sockets and
> > various GUIs and we work with specific file formats such as Elf, jpeg
> > etc. And we work with specific concepts such as files and data
> > streams. *All* of these are up for grabs when writing an OS.
>
> They are also frequently up for grabs in embedded systems, where most C
> programmers operate these days.

OK.

Why? Is it that the embedded development market in C is so large that
it dwarfs anything done elsewhere or is it that C has been replaced
with something else for development under Unix and Windows? The latter
would be sad!

> >>> I don't understand but am interested in the idea. What has changed to
> >>> make this no longer the case?
>
> >> Optimisation technology.
>
> > I don't see this. I was talking about how C operations are those you
> > will find on a CPU's ALU: arithmetic, shifts, bitwise operations; and
> > how C's data types map to typical CPU data types: signed and unsigned
> > integers and bitfields of different widths, floats of differing types.
> > Surely these are not dependent on optimisation.
>
> You could say the same for any programming language.  C does allow you
> to specify exact with types, but they are provided to enable C to
> interface with low level entities.  Most C programs won't use them.

Sure. Those types are ideal for what I want to do.

> How an instance of a type is manipulated is very much dependent on
> optimisation.  A declared variable may not even exist in optimised code.
>   The machine instructions emitted by an optimising compiler often bear
> little resemblance to the code written by the programmer. Functions get
> inlined, instructions get reordered and so on.

I understand where you were coming from now - and others have said
similar. But this is missing the point. I don't care about reorganised
code or elided operations. In terms of operations the value of C is in
being able to keep to low level concepts in the source - and be
virtually guaranteed that the generated code will be at least as
simple/fundamental.

James

[James Harris]

On Dec 11, 12:57 am, jacob navia <ja...@spamsink.net> wrote:
> Le 11/12/11 00:10, James Harris a écrit :
>
>
>
> > I have an answer to the original question: despite some negatives such
> > as its size gcc appears to be the closest fit to what I was looking
> > for. However, I have found that trying to work with it tends to
> > constrain the design. I keep finding I am making the design fit the
> > compiler. So for the time being I am sticking with assembler. Once the
> > design is stable I will look at interfacing to HLLs and compilers.
>
> Gcc is too big for what you want. You need a compiler that you can
> possibly understand or have someone that can help you out with a
> question, etc.

<valid points about the difficulty of modifying gcc source snipped>

Gcc is not perfect but nothing is. Remember the list of requirements:

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

Well, gcc fits most of these. It only really falls down badly on the
one you have highlighted, being easily ported - but that is just one
failing. As I say, nothing was perfect.

How to deal with that failing? Easy. Stick to standard, portable, C.
(That was the first requirement.) Then, if and when I get to that
point, port the smallest and simplest compiler I can find. As long as
the compiler compiles standard C it should get the system working. I
can worry about efficiency later.

James

[James Harris]

On Dec 11, 3:45 am, Seebs <usenet-nos...@seebs.net> wrote:

> On 2011-12-11, James Harris <james.harri...@googlemail.com> wrote:
>
> > I understand the point. However, from what I have done so far I can
> > see it would be easy to miss useful innovations by being influenced by
> > existing systems. The whole point of writing a new OS is to do things
> > in a new way. So my intention is as far as possible to make a clean
> > design and then to provide interfacing as needed.
>
> Hmm.  Well, it's an interesting experiment, anyway.  I'm not sure I'd expect
> it to yield significant advantages.

One has to be realistic. Many innovations are devised by teams at
universities or of professionals. They have a pool of brainpower to
call on and to interact with.

However, given enough time, enthusiasm and a refusal to do something
because "that's what is done" it is surprising what can be come up
with.

> > If I can wax lyrical for a moment: How often does a programmer get to
> > write something that is totally independent of existing systems?
> > Almost never.
>
> I have rarely *wanted* to.  Interactions with stuff is what makes things
> interesting.

Oh, there are *plenty* of interactions still! It's just that one
starts with a clean slate.

I understand your point, though.

> > I don't see this. I was talking about how C operations are those you
> > will find on a CPU's ALU: arithmetic, shifts, bitwise operations; and
> > how C's data types map to typical CPU data types: signed and unsigned
> > integers and bitfields of different widths, floats of differing types.
> > Surely these are not dependent on optimisation.
>
> For an obvious example that someone recently brought up:  Many ARM processors
> lack a divider in hardware.
>
> So there's often, for even the most primitive operations, substantial code
> generation going on behind the scenes.

That's OK. The main thing is to keep the source to just simple
operations, the data types to bytes and multiples of machine words,
and the structures to things which will be predictably translated into
assembler. Then there shouldn't be any unwanted surprises.

James

[James Harris]

That's OK. I was saying C was the most suitable language I know
because the source can use the simple concepts necessary to carry out
what I want to do. Other languages generally have programmer-friendly
features that, while convenient, could be translated into something
very inefficient or practically impossible to interface with. A C
optimiser rearranging things doesn't change the essential simplicity
of the correspondence between the C source and the CPU the machine
code will run on.

James

[James Kuyper]

On 12/12/2011 02:46 PM, James Harris wrote:
...

> possible. It should not compile for a certain target OS but merely
> produce simple, lean, unencumbered, OS-agnostic object code,

I'm a little confused by the implications of that last requirement. It
seems to me that there's generally no reason for a compiler to produce
object code that is anything other than OS-agnostic, except when making
use of OS facilities, in which case OS-agnostic code is impossible.
Could you please give a detailed real-world example of a compiler that
generates object code which is unnecessarily OS-dependent?

By "detailed", I mean the following: please provide a simple piece of
portable C source code. Identify the specific compiler you're talking
about, and specify the command line options used to invoke it. Provide a
listing of the generated object code, and identify the specific ways in
which the generated object code is unnecessarily OS-dependent. To make
it clearer what you're looking for, please also provide corresponding
object code that would meet your specification.

[James Harris]

On Dec 10, 11:20 pm, Seebs <usenet-nos...@seebs.net> wrote:

> On 2011-12-10, James Harris <james.harri...@googlemail.com> wrote:
>
> > I did say (in the title/subject) that this is for development of an OS
> > - an operating system. As such, no, this is not for a hosted platform.
> > The 'platform' itself is being defined, as is the ABI.
>
> I would point out that ABIs are often defined by the architecture in some
> way.  There is a "MIPS ABI" (well, there's several) which exists independent
> of your choice of operating system.

There's very little mandated by the CPU that I can think of. What did
you have in mind? A given CPU may have an instruction pointer
register, a stack pointer register and/or dedicated registers for use
in call and return instructions but the definitions of how parameters
are passed, which registers are caller-save and which are callee-save
and how return addresses are stored when a sub-sub-routine is called
etc are generally just conventions aren't they?

Besides, since we are focussing on the ABI, I think the mechanism
would probably be relevant to the CPU type, not to the OS as a whole.
In other words, one OS but each platform could have its own calling
conventions - the ones that were most appropriate for that hardware.

> >> > Taking a step back, consider a C anomaly. Look at how low-level C is
> >> > and why it is favoured as a 'portable assembler' (not a phrase I am
> >> > recommending) by compiler writers and others. In C there is usually a
> >> > clear, direct and simple correspondence between C operations and a
> >> > CPU's opcodes, and a similar correspondence between C data types and
> >> > those supported by the CPU.
> >> Once upon a time long ago, maybe. ?This certainly isn't the case today.
> > I don't understand but am interested in the idea. What has changed to
> > make this no longer the case?
>
> Well, strictly speaking, it never was.  Consider:
>
>         long a, b, c;
>         a = get_a_number();
>         b = get_a_number();
>         c = a * b;
>
> I'm pretty sure this has been implemented in software on at least some C
> implementations since the 70s, because there have been 32-bit longs on 16-bit
> systems.
>
> Similarly, 64-bit values on 32-bit systems, floating point math on machines
> with no FPU...  The list goes on, and on, and on.
>
> C hasn't really been much for 1:1 correspondences in a very long time.  I
> think the most obvious cutoff, if you wanted one, would be struct assignment.

I think I may have mislead people as that's not what I had in mind. As
explained in reply to others I can predict the basics of what C will
do with my code on a given architecture. If it makes things better
than I thought of that's fine. The key point is that it won't
(normally) do nasty things that I don't expect. I can't say that of
any other HLL.

> > As the OS is new there is no host software at all. The OS's use of the
> > CPU is fairly generic and could apply to various processors. So all of
> > the structure and interface is up for definition.
>
> If you don't use a standard ABI for each CPU, you will have a much harder
> time.

True.

> > Well, the interface to the OS will be well defined but the design is
> > intended to be based on first principles and, as far as possible, to
> > avoid influence from existing systems.
>
> I think C is the wrong tool for this, then, as a great deal of the benefit of
> C is a mature ecosystem for using standard ABIs.

You may be right. The trouble is I don't know of anything better. Do
you?

James

[Seebs]

On 2011-12-12, James Harris <james.h...@googlemail.com> wrote:
> However, given enough time, enthusiasm and a refusal to do something
> because "that's what is done" it is surprising what can be come up
> with.

Yes. But not always *good* surprising. :)

>> So there's often, for even the most primitive operations, substantial code
>> generation going on behind the scenes.

> That's OK. The main thing is to keep the source to just simple
> operations, the data types to bytes and multiples of machine words,
> and the structures to things which will be predictably translated into
> assembler. Then there shouldn't be any unwanted surprises.

I've used a machine with 32-bit words and 80-bit floats. :)

I think the fact is, there's always gonna be surprises with a good compiler,
especially with decent optimization.

[Seebs]

On 2011-12-12, James Kuyper <james...@verizon.net> wrote:
> I'm a little confused by the implications of that last requirement. It
> seems to me that there's generally no reason for a compiler to produce
> object code that is anything other than OS-agnostic, except when making
> use of OS facilities, in which case OS-agnostic code is impossible.
> Could you please give a detailed real-world example of a compiler that
> generates object code which is unnecessarily OS-dependent?

ABI is often specified by OS, and two OSs might specify incompatible ABIs.

I don't think that's unnecessary, and it's not *really* OS-dependent, but
the net result is that you can't exchange binary code between conflicting
models.

[Seebs]

On 2011-12-12, James Harris <james.h...@googlemail.com> wrote:

> On Dec 10, 11:20?pm, Seebs <usenet-nos...@seebs.net> wrote:
>> I would point out that ABIs are often defined by the architecture in some

>> way. ?There is a "MIPS ABI" (well, there's several) which exists independent

>> of your choice of operating system.

> There's very little mandated by the CPU that I can think of.

Not mandated by the CPU, but defined and documented by the CPU vendor.

Look, you can make any calling convention you want. If you don't use
the standard ABI defined by the MIPS architecture, though, no one will
interoperate with your code, or care about it.

> which registers are caller-save and which are callee-save
> and how return addresses are stored when a sub-sub-routine is called
> etc are generally just conventions aren't they?

Sure.

But if you ignore those conventions, you have just eliminated any reason
for anyone to try to interoperate with your code, support your platform,
or otherwise interact with you at all.

I have two choices: I can spend half an hour adding flawless support for
someone who followed published standards, or I can spend months adding
buggy support for someone who ignored them. Which of these choices is going
to give me a better return on my time?

> Besides, since we are focussing on the ABI, I think the mechanism
> would probably be relevant to the CPU type, not to the OS as a whole.
> In other words, one OS but each platform could have its own calling
> conventions - the ones that were most appropriate for that hardware.

Why, yes. And that's the thing. If you target 64-bit mips, but don't use
the standard 64-bit ABI, you have chosen irrelevance preemptively. You're
basically guaranteed not to get any support or buy-in, and without that,
it's a purely academic research project.

> I think I may have mislead people as that's not what I had in mind. As
> explained in reply to others I can predict the basics of what C will
> do with my code on a given architecture. If it makes things better
> than I thought of that's fine. The key point is that it won't
> (normally) do nasty things that I don't expect. I can't say that of
> any other HLL.

I guess it depends on what you expect, doesn't it?

Consider:

int x, y = 3;
x = y;

Assume that int is 32 bits. How many instructions will be used to perform
this operation, and how much data will be loaded to or from registers or
memory?

Answers I've seen include:

* No instructions, because the optimizer discarded one or both of the
variables.
* No instructions, because the optimizer arranged for them to have the
right values in advance.
* Both are in registers.
* Neither is in a register.
* They're both in memory. To perform the operation, the compiler generates
code to load a 16-byte vector starting with y into one register, load
another 16-byte vector starting with x into another register, load an
immediate value into another register, use the immediate value to mask
the first four bytes of y into the first four bytes of x, then save that
16-byte chunk of memory back to main memory.

> You may be right. The trouble is I don't know of anything better. Do
> you?

I don't think there exists a good tool for developing a competing ABI in
the absence of a really, really, compelling argument that a better ABI is
needed.

[James Harris]

On Dec 12, 8:15 pm, Seebs <usenet-nos...@seebs.net> wrote:

> On 2011-12-12, James Harris <james.harri...@googlemail.com> wrote:
>
> > On Dec 10, 11:20?pm, Seebs <usenet-nos...@seebs.net> wrote:
> >> I would point out that ABIs are often defined by the architecture in some
> >> way. ?There is a "MIPS ABI" (well, there's several) which exists independent
> >> of your choice of operating system.
> > There's very little mandated by the CPU that I can think of.
>
> Not mandated by the CPU, but defined and documented by the CPU vendor.

Exactly.

> Look, you can make any calling convention you want.  If you don't use
> the standard ABI defined by the MIPS architecture, though, no one will
> interoperate with your code, or care about it.

Now I understand what you are thinking of. That's not my intention.
Remember I spoke of not wanting to be constrained by existing systems?
The calling convention is a case in point. If I followed existing
conventions across the board it would influence the design *far* too
much. I've already looked at that.

Instead the approach is to design the convention for the OS internals
with reference only to what's best for the internals themselves and
the desired execution environment and ignore (or, better still, not
even find out) what everyone else does. When that is done, tested,
reviewed and stabilised is the right time to look at making shims (my
term, AFAIK) to allow linkage to/from other code as appropriate.

This principle applies in many areas of the OS design. Get the
internals right. Only once done look at interfacing to traditional
systems where necessary.

...

This is not relevant to my argument. (Though I accept it may be to
yours.) I'll try to explain what I mean by giving some reasons why C
is good. Maybe that will explain the scope and show why the assignment
you showed is a non-sequitur.

C provides sized integers, it provides both signed and unsigned
integers. It provides pointers that can refer to almost anything
including functions and I can rely on the size of those pointers (on a
given compiler). It does not do any automatic reference counting. It
provides no autonomous memory management. It provides structuring I
can rely on. It provides operations that I can mentally map to CPU
opcodes. Where a CPU does not support certain instructions like divide
I can rely on the compiler making suitable choices, etc, etc.

Of course, I can do all the above in assembler. One key thing C adds
is CPU-independence (and it should be easier to use).

James

[James Harris]

I got an answer to my original question a while ago. I'm happy to
respond to questions or challenges but can't quite summon up the
motivation to do what you ask for. Thanks, if you were trying to help,
though.

James

[James Kuyper]

No, I wasn't trying to help; I was trying to figure out what you were
talking about. What you appear to be saying is incompatible with my
mental model of how compilers and operating systems interact. Either I'm
misunderstanding you, or my model is incorrect, or what you're saying
doesn't make sense; I'm not sure which, and I wanted to find out.

If what you're saying doesn't make sense, then proving that fact to your
satisfaction would be helpful to you. However, if either of the other
two options apply, you won't derive any benefit from resolving the issue
for me, and I can't claim that you have any duty to do so.

Though my career has been in scientific computing, my formal education
was in advanced theoretical physics, not computer science. I've learned
a lot about how compilers work in the course of my career, but I've
never even taken the kind of course, which I gather is standard for Comp
Sci students, in which you actually write a simple compiler.

I only have a limited range of actual experience with operating systems.
The vast majority of my computer programming has been on variety of
Unix-like operating systems - mostly, and most recently, several
different distributions of Linux. Most of the rest of my experience was
a long time ago on MS-DOS machines, plus one summer I spent writing code
for a VMS system.

Therefore, it's entirely possible that my model of compiler/OS
interactions is incorrect, or at least incomplete.

[Keith Thompson]

James Harris <james.h...@googlemail.com> writes:
[...]

> That's OK. I was saying C was the most suitable language I know
> because the source can use the simple concepts necessary to carry out
> what I want to do. Other languages generally have programmer-friendly
> features that, while convenient, could be translated into something
> very inefficient or practically impossible to interface with. A C
> optimiser rearranging things doesn't change the essential simplicity
> of the correspondence between the C source and the CPU the machine
> code will run on.

I wonder if C-- would suit your purposes better.
<http://www.goosee.com/cmm/>.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Seebs]

On 2011-12-12, James Harris <james.h...@googlemail.com> wrote:

> Now I understand what you are thinking of. That's not my intention.
> Remember I spoke of not wanting to be constrained by existing systems?
> The calling convention is a case in point. If I followed existing
> conventions across the board it would influence the design *far* too
> much. I've already looked at that.

Then there are two possibilities:
1. You are DRAMATICALLY smarter than everyone who has ever worked on this.
2. What you are doing is absolutely doomed to irrelevance from the start.

I can't see it as remotely possible that messing with calling conventions
is going to provide sufficiently enormous benefits to make a system which
invents its own of any interest. The cost of interoperability will be
huge; unless you have transcendently gigantic benefits on the table, that
means it's not interesting.

So basically, this is an interesting amusement, but that design decision
rules out from the beginning any chance of it yielding anything useful
except experience.

> C provides sized integers, it provides both signed and unsigned
> integers. It provides pointers that can refer to almost anything
> including functions and I can rely on the size of those pointers (on a
> given compiler).

There can be *at least* three distinct classes of pointers. Real systems
have existed on which pointer-to-function, pointer-to-struct, and
pointer-to-void were three different kinds of objects, and not
interchangeable. I suspect at least a few are still in use.

> It does not do any automatic reference counting. It
> provides no autonomous memory management. It provides structuring I
> can rely on. It provides operations that I can mentally map to CPU
> opcodes. Where a CPU does not support certain instructions like divide
> I can rely on the compiler making suitable choices, etc, etc.

Except the mental mapping to CPU opcodes is liable to be wrong. That
makes it, I'd think, sort of a negative.

[Robert Wessel]

On Mon, 12 Dec 2011 12:38:13 -0800 (PST), James Harris
<james.h...@googlemail.com> wrote:

>On Dec 10, 11:20 pm, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2011-12-10, James Harris <james.harri...@googlemail.com> wrote:
>>
>> > I did say (in the title/subject) that this is for development of an OS
>> > - an operating system. As such, no, this is not for a hosted platform.
>> > The 'platform' itself is being defined, as is the ABI.
>>
>> I would point out that ABIs are often defined by the architecture in some
>> way.  There is a "MIPS ABI" (well, there's several) which exists independent
>> of your choice of operating system.
>
>There's very little mandated by the CPU that I can think of. What did
>you have in mind? A given CPU may have an instruction pointer
>register, a stack pointer register and/or dedicated registers for use
>in call and return instructions but the definitions of how parameters
>are passed, which registers are caller-save and which are callee-save
>and how return addresses are stored when a sub-sub-routine is called
>etc are generally just conventions aren't they?

While less than mandated, a number of ISA have strongly encouraged a
particular convention, or at least some attributes thereof. For
example, VAX's standard subroutine call instructions. And while those
were too heavyweight for internal uses (most compilers generating
BSB/JSB instead of CALLG/CALLS), they largely defined the
intra-program and system calling convention on a number of the OSs.

[Ian Collins]

On 12/13/11 09:38 AM, James Harris wrote:
> On Dec 10, 11:20 pm, Seebs<usenet-nos...@seebs.net> wrote:
>> On 2011-12-10, James Harris<james.harri...@googlemail.com> wrote:
>>
>>> I did say (in the title/subject) that this is for development of an OS
>>> - an operating system. As such, no, this is not for a hosted platform.
>>> The 'platform' itself is being defined, as is the ABI.
>>
>> I would point out that ABIs are often defined by the architecture in some
>> way. There is a "MIPS ABI" (well, there's several) which exists independent
>> of your choice of operating system.
>
> There's very little mandated by the CPU that I can think of. What did
> you have in mind? A given CPU may have an instruction pointer
> register, a stack pointer register and/or dedicated registers for use
> in call and return instructions but the definitions of how parameters
> are passed, which registers are caller-save and which are callee-save
> and how return addresses are stored when a sub-sub-routine is called
> etc are generally just conventions aren't they?

Not just conventions in cases such as Sparc where register wheels are
used for in/local/out registers.

> Besides, since we are focussing on the ABI, I think the mechanism
> would probably be relevant to the CPU type, not to the OS as a whole.
> In other words, one OS but each platform could have its own calling
> conventions - the ones that were most appropriate for that hardware.

Which is how things are normally done.

--
Ian Collins

[Robert Wessel]

On Mon, 12 Dec 2011 15:23:26 -0500, James Kuyper
<james...@verizon.net> wrote:

>On 12/12/2011 02:46 PM, James Harris wrote:
>...
>> possible. It should not compile for a certain target OS but merely
>> produce simple, lean, unencumbered, OS-agnostic object code,
>
>I'm a little confused by the implications of that last requirement. It
>seems to me that there's generally no reason for a compiler to produce
>object code that is anything other than OS-agnostic, except when making
>use of OS facilities, in which case OS-agnostic code is impossible.
>Could you please give a detailed real-world example of a compiler that
>generates object code which is unnecessarily OS-dependent?

Obviously general calling conventions impact things like debuggers as
well as the obvious ability to call other code, compilers generate
system-dependent stack probes on some systems, some things may depend
on the assumed state of certain resources (consider inlining cos() on
x86 - the required code depends on what state the FPU is in), the
presence of threading might impact generated code, exactly how the
system loads code and data areas, and which areas are actually
writeable. I'm sure there are others.

[James Kuyper]

But is there any compiler that unnecessarily does such things? I would
think that generating such code is a necessity, in most contexts; and in
the unlikely case that it's not a necessity, I would expect the compiler
to have, at least as an option, the ability to not generate such code.
I know, in particular, that inlining cos() calls has been optional on
every compiler I've used where it was a) possible to inline them and b)
reasonable, under some circumstances, to not do so.

[Robert Wessel]

On Tue, 13 Dec 2011 12:03:54 +1300, Ian Collins <ian-...@hotmail.com>
wrote:

>On 12/13/11 09:38 AM, James Harris wrote:
>> On Dec 10, 11:20 pm, Seebs<usenet-nos...@seebs.net> wrote:
>>> On 2011-12-10, James Harris<james.harri...@googlemail.com> wrote:
>>>
>>>> I did say (in the title/subject) that this is for development of an OS
>>>> - an operating system. As such, no, this is not for a hosted platform.
>>>> The 'platform' itself is being defined, as is the ABI.
>>>
>>> I would point out that ABIs are often defined by the architecture in some
>>> way. There is a "MIPS ABI" (well, there's several) which exists independent
>>> of your choice of operating system.
>>
>> There's very little mandated by the CPU that I can think of. What did
>> you have in mind? A given CPU may have an instruction pointer
>> register, a stack pointer register and/or dedicated registers for use
>> in call and return instructions but the definitions of how parameters
>> are passed, which registers are caller-save and which are callee-save
>> and how return addresses are stored when a sub-sub-routine is called
>> etc are generally just conventions aren't they?
>
>Not just conventions in cases such as Sparc where register wheels are
>used for in/local/out registers.

Like with the VAX example I used, SPARC's register windows offer some
pretty strong nudges, but doesn't quite mandate the calling
convention. It's entirely possible (although not necessarily a good
idea) to program SPARC while ignoring the register windows (IOW, avoid
SAVE/RESTORE and treat the machine as having ~32 conventional
registers). At least up to the point where you need to call/be called
by code using the standard conventions.

[Eric Sosman]

On 12/12/2011 3:38 PM, James Harris wrote:
> [...]

> There's very little mandated by the CPU that I can think of. What did
> you have in mind? A given CPU may have an instruction pointer
> register, a stack pointer register and/or dedicated registers for use
> in call and return instructions but the definitions of how parameters
> are passed, which registers are caller-save and which are callee-save
> and how return addresses are stored when a sub-sub-routine is called
> etc are generally just conventions aren't they?

You're probably right that the CPU doesn't "mandate" subroutine
linkage conventions. You're free to ignore that tempting stack, those
automatically-turned register windows, and whatever other doodads the
CPU provides for your convenience. If you feel like it, you can write
all the arguments to a disk file and have the subroutine read them
back again.

> Besides, since we are focussing on the ABI, I think the mechanism
> would probably be relevant to the CPU type, not to the OS as a whole.
> In other words, one OS but each platform could have its own calling
> conventions - the ones that were most appropriate for that hardware.

If you plan to write everything yourself, and to make no use of
tools or components developed in the outside world, this is viable.
But if you want to leverage independent work, you must give thought to
doing things in a way that will ease, or at least not impede, the
integration of the parts.

Real-world example: In a former life I worked for the late, great
Sun Microsystems. One continuing and exasperating problem was getting
good device drivers for desirable gadgets dreamed up by third parties.
Company X has a super-duper-speed fibre channel adapter, Company Y has
a video card that is all the rage, and so on. The first thing the
companies do is provide device drivers for a couple flavors of Windows,
then maybe Linux -- but because Solaris had its own device driver
framework, we often wound up with no driver, or paid Companies X,Y,Z
for slapdash inferior drivers ... because we were "better."

Arthur Clarke wrote a story called "Superiority." Read it, if
you can find it somewhere.

--
Eric Sosman
eso...@ieee-dot-org.invalid

[John Tsiombikas]

On 2011-12-12, Seebs <usenet...@seebs.net> wrote:
> On 2011-12-12, James Harris <james.h...@googlemail.com> wrote:
>
>> That's OK. The main thing is to keep the source to just simple
>> operations, the data types to bytes and multiples of machine words,
>> and the structures to things which will be predictably translated into
>> assembler. Then there shouldn't be any unwanted surprises.
>
> I've used a machine with 32-bit words and 80-bit floats. :)

I think most people have. All 32bit x86 processors with an x87 fpu fit
this spec.


--
John Tsiombikas
http://nuclear.mutantstargoat.com/

[Robert Wessel]

On 13 Dec 2011 06:28:47 GMT, John Tsiombikas <nuc...@member.fsf.org>
wrote:

While the hardware supports it, the standard tools for Windows don't
expose the 80-bit format, except in assembler. So the majority of
people may be running on machines with native 80 bit floats, but
mostly don't get to see anything longer than 64.

[John Tsiombikas]

On 2011-12-12, Seebs <usenet...@seebs.net> wrote:

> On 2011-12-12, James Harris <james.h...@googlemail.com> wrote:
>> Now I understand what you are thinking of. That's not my intention.
>> Remember I spoke of not wanting to be constrained by existing systems?
>> The calling convention is a case in point. If I followed existing
>> conventions across the board it would influence the design *far* too
>> much. I've already looked at that.
>
> Then there are two possibilities:
> 1. You are DRAMATICALLY smarter than everyone who has ever worked on this.
> 2. What you are doing is absolutely doomed to irrelevance from the start.

I'm not saying this discussion doesn't have some interesting posts here
and there, but I don't understand why is everyone trying so passionately
to convince the OP to not try out his ideas about different calling
conventions in his own operating system. If he feels like it, I think
that's justification enough for me.

P.S. I'm also writing an operating system currently, and I'm following
the established calling conventions mostly because I don't think I would
have anything to gain by not doing it, but also because I'm too lazy to
start modifying compilers, linkers and debuggers on top of everything
else.

[io_x]

"Eric Sosman" <eso...@ieee-dot-org.invalid> ha scritto nel messaggio
news:jc6327$23u$1...@dont-email.me...

> Real-world example: In a former life I worked for the late, great
> Sun Microsystems. One continuing and exasperating problem was getting
> good device drivers for desirable gadgets dreamed up by third parties.
> Company X has a super-duper-speed fibre channel adapter, Company Y has
> a video card that is all the rage, and so on. The first thing the
> companies do is provide device drivers for a couple flavors of Windows,
> then maybe Linux -- but because Solaris had its own device driver
> framework, we often wound up with no driver, or paid Companies X,Y,Z
> for slapdash inferior drivers ... because we were "better."

is it difficult emulate the min WindowsOS For Y-cpu[i don't know if
it exist for cpu out x86] enviroment
so the drivers can work in Solaris for the same Y-cpu too
even if they are build for one the other OS?

there are legal problems in that? [emulate part of one other OS]

[Seebs]

On 2011-12-13, John Tsiombikas <nuc...@member.fsf.org> wrote:
> I'm not saying this discussion doesn't have some interesting posts here
> and there, but I don't understand why is everyone trying so passionately
> to convince the OP to not try out his ideas about different calling
> conventions in his own operating system. If he feels like it, I think
> that's justification enough for me.

You have a point here. I guess... The impression I get is that he has
underestimated the importance for interoperability, and unimportance for
performance, of standard calling conventions. I could be wrong. But it's
nearly always the case that when someone starts talking about a new ABI
for existing hardware with a stable ABI, it's going to be a bad idea.

[jacob navia]

Le 13/12/11 07:32, Robert Wessel a écrit :

Unless they use lcc-win of course, that provides true 80 bits
floating point, and true output of that data with printf.

[James Harris]

On Dec 12, 10:32 pm, Seebs <usenet-nos...@seebs.net> wrote:

> On 2011-12-12, James Harris <james.harri...@googlemail.com> wrote:
>
> > Now I understand what you are thinking of. That's not my intention.
> > Remember I spoke of not wanting to be constrained by existing systems?
> > The calling convention is a case in point. If I followed existing
> > conventions across the board it would influence the design *far* too
> > much. I've already looked at that.
>
> Then there are two possibilities:
> 1.  You are DRAMATICALLY smarter than everyone who has ever worked on this.
> 2.  What you are doing is absolutely doomed to irrelevance from the start.

I like the dramatic way you express things. :-) It does help me
understand your point of view. Are you thinking that the calling
conventions are an end in themselves?

In fact, the calling conventions we are discussing are designed to
support the tasking model which is somewhat different from the norm.
For example, individual functions should be replaceable while they are
running. Yes, really. I'm not going to go into the details here as the
OS design, so far, has many parts which interrelate and one part in
isolation would likely lead to a long and unsatisfactory discussion.

I will, however, mention something more conventional to illustrate
some of the reasons for the design of a specific calling convention.
As well as the dynamic replacement, the calling supports non-mandatory
dynamic linking and lazy linking. I had to find a way to make these
very efficient. And, for various reasons, I needed a way for user-mode
code to make system calls without knowing whether the called routine
was privileged or not. Don't worry about the details. The point is
that the preferred calling convention is specific for very good
reasons.

I know I could have worked with a shell round an existing calling
convention but whatever I considered would not have been even remotely
as efficient. In this case the calling convention does influence the
design because I wouldn't have been able to come up with the design
that I have if I couldn't make the calling efficient.

...

> > C provides sized integers, it provides both signed and unsigned
> > integers. It provides pointers that can refer to almost anything
> > including functions and I can rely on the size of those pointers (on a
> > given compiler).
>
> There can be *at least* three distinct classes of pointers.  Real systems
> have existed on which pointer-to-function, pointer-to-struct, and
> pointer-to-void were three different kinds of objects, and not
> interchangeable.  I suspect at least a few are still in use.

What sort of systems? Do you mean, "compilers" or "operating systems"
or something else?

James

[Seebs]

On 2011-12-14, James Harris <james.h...@googlemail.com> wrote:
> I like the dramatic way you express things. :-) It does help me
> understand your point of view. Are you thinking that the calling
> conventions are an end in themselves?

No, rather I was thinking the opposite; unless your purpose is specifically
to research calling conventions, it's highly likely that the penalties
from replacing calling conventions will trump the benefits.

> And, for various reasons, I needed a way for user-mode
> code to make system calls without knowing whether the called routine
> was privileged or not. Don't worry about the details. The point is
> that the preferred calling convention is specific for very good
> reasons.

I am not comprehending this part. Existing calling conventions are like
that too. You don't have to know anything about the called routine; that's
why it's a convention.

In systems where there's a distinction between "library calls" and
"system calls", the practical reality is that nearly always, the library
contains callable functions (using standard calling conventions)
which wrap the "system calls".

> I know I could have worked with a shell round an existing calling
> convention but whatever I considered would not have been even remotely
> as efficient.

It doesn't seem to be hurting performance in any of the systems I know
currently doing it.

>> There can be *at least* three distinct classes of pointers. ?Real systems

>> have existed on which pointer-to-function, pointer-to-struct, and
>> pointer-to-void were three different kinds of objects, and not

>> interchangeable. ?I suspect at least a few are still in use.

> What sort of systems? Do you mean, "compilers" or "operating systems"
> or something else?

"Systems" meaning "implementations", which tends to be the trio of compiler,
operating system, and hardware. So for instance, given an x86 system,
you could have different operating systems, and different compilers running
under those operating systems. And you could have the same compiler running
under two of those operating systems. And each of these might give you
different rules in some cases; although we've mostly left the days of having
to care about "near" and "far" pointers, there were certainly cases where
there were distinct pointer types in living memory, and there likely will
be again.

[James Harris]

On Dec 12, 10:25 pm, Keith Thompson <ks...@mib.org> wrote:

> James Harris <james.harri...@googlemail.com> writes:
>
> [...]
>
> > That's OK. I was saying C was the most suitable language I know
> > because the source can use the simple concepts necessary to carry out
> > what I want to do. Other languages generally have programmer-friendly
> > features that, while convenient, could be translated into something
> > very inefficient or practically impossible to interface with. A C
> > optimiser rearranging things doesn't change the essential simplicity
> > of the correspondence between the C source and the CPU the machine
> > code will run on.
>
> I wonder if C-- would suit your purposes better.
> <http://www.goosee.com/cmm/>.

Thanks for the suggestion. I'll certainly take a look.

James

[Ian Collins]

On 12/15/11 10:00 AM, James Harris wrote:

<snips>

> I know I could have worked with a shell round an existing calling
> convention but whatever I considered would not have been even remotely
> as efficient.

The wrapper, if present (some compilers are smart/OS aware enough to
inline them), the overhead of a wrapper is trivial compared to the
actual call into kernel space.

> In this case the calling convention does influence the
> design because I wouldn't have been able to come up with the design
> that I have if I couldn't make the calling efficient.

You appear to be hung up on potential efficiency, have you actually made
some real world measurements?

>>> C provides sized integers, it provides both signed and unsigned
>>> integers. It provides pointers that can refer to almost anything
>>> including functions and I can rely on the size of those pointers (on a
>>> given compiler).
>>
>> There can be *at least* three distinct classes of pointers. Real systems
>> have existed on which pointer-to-function, pointer-to-struct, and
>> pointer-to-void were three different kinds of objects, and not
>> interchangeable. I suspect at least a few are still in use.
>
> What sort of systems? Do you mean, "compilers" or "operating systems"
> or something else?

I've used systems with separate data and programme memory (with
different bus widths), so data pointers were a different beast form
function pointers. Google Harvard architecture

--
Ian Collins

[James Harris]

On Dec 14, 10:18 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 12/15/11 10:00 AM, James Harris wrote:
>
> <snips>
>
> > I know I could have worked with a shell round an existing calling
> > convention but whatever I considered would not have been even remotely
> > as efficient.
>
> The wrapper, if present (some compilers are smart/OS aware enough to
> inline them), the overhead of a wrapper is trivial compared to the
> actual call into kernel space.

There's a lot of truth in this but kernel calls on some machines are
much faster than they used to be. Also, 1) especially for machines
that need it I have come up with a number of ways to reduce the number
of transitions, 2) at least in the bit you quoted I was talking about
calling between functions in general, not just privilege transitions.

> > In this case the calling convention does influence the
> > design because I wouldn't have been able to come up with the design
> > that I have if I couldn't make the calling efficient.
>
> You appear to be hung up on potential efficiency, have you actually made
> some real world measurements?

Guilty as charged. I am highly focussed on efficiency for the OS both
at the micro and, more importantly, the macro levels. Yes, I have made
a lot of real-world measurements and studied CPU internals.

James

[James Harris]

On Dec 12, 11:34 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 12/12/2011 3:38 PM, James Harris wrote:
>
> > [...]
> > There's very little mandated by the CPU that I can think of. What did
> > you have in mind? A given CPU may have an instruction pointer
> > register, a stack pointer register and/or dedicated registers for use
> > in call and return instructions but the definitions of how parameters
> > are passed, which registers are caller-save and which are callee-save
> > and how return addresses are stored when a sub-sub-routine is called
> > etc are generally just conventions aren't they?
>
>      You're probably right that the CPU doesn't "mandate" subroutine
> linkage conventions.  You're free to ignore that tempting stack, those
> automatically-turned register windows, and whatever other doodads the
> CPU provides for your convenience.  If you feel like it, you can write
> all the arguments to a disk file and have the subroutine read them
> back again.

Well, I could, but I am looking for slightly better performance than
that. :^)

> > Besides, since we are focussing on the ABI, I think the mechanism
> > would probably be relevant to the CPU type, not to the OS as a whole.
> > In other words, one OS but each platform could have its own calling
> > conventions - the ones that were most appropriate for that hardware.
>
>      If you plan to write everything yourself, and to make no use of
> tools or components developed in the outside world, this is viable.
> But if you want to leverage independent work, you must give thought to
> doing things in a way that will ease, or at least not impede, the
> integration of the parts.
>
>      Real-world example: In a former life I worked for the late, great
> Sun Microsystems.  One continuing and exasperating problem was getting
> good device drivers for desirable gadgets dreamed up by third parties.
> Company X has a super-duper-speed fibre channel adapter, Company Y has
> a video card that is all the rage, and so on.  The first thing the
> companies do is provide device drivers for a couple flavors of Windows,
> then maybe Linux -- but because Solaris had its own device driver
> framework, we often wound up with no driver, or paid Companies X,Y,Z
> for slapdash inferior drivers ... because we were "better."

Principle understood and agreed with. For the specifics of device
drivers any OS developer is in a no-win situation. It is quite
impossible to develop for the vast number of devices out there. There
are simply far too many of them. At my level all one can do is control
standard devices and provide an environment for other device drivers
to run in. Even that is a daunting task and I've hardly scratched the
surface.

>      Arthur Clarke wrote a story called "Superiority."  Read it, if
> you can find it somewhere.

I remember it. I'm a big fan of Arthur C Clarke's stories.

James

[Seebs]

On 2011-12-15, James Harris <james.h...@googlemail.com> wrote:
> Guilty as charged. I am highly focussed on efficiency for the OS both
> at the micro and, more importantly, the macro levels. Yes, I have made
> a lot of real-world measurements and studied CPU internals.

I'd be really interested in seeing what kinds of numbers you're seeing
for real-world code. I've seen far too many benchmarks wherein people
establish that they are able to trim 10% off a particular hunk of syscall
operations... without considering that when actual data are involved, that
hunk of syscall operations is maybe 2% of the total time spent processing
the syscall. :)

[James Harris]

On Dec 12, 11:19 pm, Robert Wessel <robertwess...@yahoo.com> wrote:
> On Tue, 13 Dec 2011 12:03:54 +1300, Ian Collins <ian-n...@hotmail.com>

> >On 12/13/11 09:38 AM, James Harris wrote:

...

> >> There's very little mandated by the CPU that I can think of. What did
> >> you have in mind? A given CPU may have an instruction pointer
> >>register, a stack pointer register and/or dedicated registers for use
> >> in call and return instructions but the definitions of how parameters
> >> are passed, which registers are caller-save and which are callee-save
> >> and how return addresses are stored when a sub-sub-routine is called
> >> etc are generally just conventions aren't they?
>
> >Not just conventions in cases such as Sparc where register wheels are
> >used for in/local/out registers.
>

> Like with the VAX example I used,SPARC's register windows offer some

> pretty strong nudges, but doesn't quite mandate the calling
> convention.  It's entirely possible (although not necessarily a good

> idea) to program SPARC while ignoring the register windows(IOW, avoid

> SAVE/RESTORE and treat the machine as having ~32 conventional
> registers).  At least up to the point where you need to call/be called
> by code using the standard conventions.

Sure. So far I have looked at Sparc, MIPS and Arm but worked out the
most detail on x86 so I can't tell you what I would do on Sparc but
since its rotating register windows are at least reputed to be very
efficient they may well figure in the OS-internal calling convention
for that machine.

James

[James Harris]

On Dec 15, 7:35 pm, Seebs <usenet-nos...@seebs.net> wrote:

> On 2011-12-15, James Harris <james.harri...@googlemail.com> wrote:
>
> > Guilty as charged. I am highly focussed on efficiency for the OS both
> > at the micro and, more importantly, the macro levels. Yes, I have made
> > a lot of real-world measurements and studied CPU internals.
>
> I'd be really interested in seeing what kinds of numbers you're seeing
> for real-world code.  I've seen far too many benchmarks wherein people
> establish that they are able to trim 10% off a particular hunk of syscall
> operations... without considering that when actual data are involved, that
> hunk of syscall operations is maybe 2% of the total time spent processing
> the syscall.  :)

I understand the point and it's a good one. I don't normally approach
it that way. To say something is x% faster than something else might
be valid for an app but it is irrelevant at the per-instruction level
I have been looking at. My interest is principally in two things:

1. Which options are as fast as expected and are any unexpectedly slow
(and if so, why)?

2. Can I learn to predict performance on a given CPU?

The second is especially relevant. For example, on an AMD CPU that I
have I can clearly see effects showing the CPU complete three single-
cycle-type instructions per clock and can determine which instructions
are that fast.

Once one knows which instructions are single-cycle-type (there must be
a better term) and identify dependencies it is not too hard to write
very efficient code sequences.

As an approach it's not perfect but it does demystify what is
otherwise a black art.

There are helpful optimisation guides from AMD and Intel but they tend
to be lists of rules without too much explanation. The best info I
have found to help understand what's going on is Agner Fog's,
especially the microarchitecture manual.

http://www.agner.org/optimize/

He has a manual for a HLL too but it's C++. :-(

James