Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #13169 > unrolled thread

Which lean C compiler for 32-bit OS development

Back to article view | Back to comp.lang.c

Contents

  Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-11-12 01:22 -0800
    Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-12 10:36 +0100
      Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-11-12 02:09 -0800
        Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-12 11:37 +0100
          Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-11-12 08:02 -0800
            Re: Which lean C compiler for 32-bit OS development Borax Man <rotflol2@hotmail.com> - 2011-11-13 10:24 +1100
            Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-13 10:29 +0100
          Re: Which lean C compiler for 32-bit OS development BGB <cr88192@hotmail.com> - 2011-11-12 15:06 -0700
      Re: Which lean C compiler for 32-bit OS development "ankh" <star67@venus.gov> - 2011-11-12 22:43 -0600
        Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-14 21:57 +0100
          Re: Which lean C compiler for 32-bit OS development Ian Collins <ian-news@hotmail.com> - 2011-11-15 10:16 +1300
          Re: Which lean C compiler for 32-bit OS development "Jo" <none@none.none> - 2011-11-19 22:59 -0600
            Re: Which lean C compiler for 32-bit OS development "BartC" <bc@freeuk.com> - 2011-11-20 12:58 +0000
              Re: Which lean C compiler for 32-bit OS development Fritz Wuehler <fritz@spamexpire-201111.rodent.frell.theremailer.net> - 2011-11-21 07:30 +0100
                Re: Which lean C compiler for 32-bit OS development "Jo" <none@none.none> - 2011-11-21 01:01 -0600
              Re: Which lean C compiler for 32-bit OS development "Jo" <none@none.none> - 2011-11-21 00:51 -0600
              Re: Which lean C compiler for 32-bit OS development Brian <nospam@nospam.com> - 2011-11-22 16:47 +0000
                Re: Which lean C compiler for 32-bit OS development James Kuyper <jameskuyper@verizon.net> - 2011-11-22 12:10 -0500
                  Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-22 20:24 +0100
                Re: Which lean C compiler for 32-bit OS development Richard Sanders <lnr729@gmail.com> - 2011-11-22 10:58 -0800
                  Re: Which lean C compiler for 32-bit OS development Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-24 00:27 -0800
                Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-22 20:13 +0100
                  Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-23 23:13 +0100
                Re: Which lean C compiler for 32-bit OS development Friedrich Dominicus <just-for-news-frido@q-software-solutions.de> - 2011-11-23 06:28 +0100
                  Re: Which lean C compiler for 32-bit OS development Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-23 02:45 -0800
                    Re: Which lean C compiler for 32-bit OS development Willem <willem@toad.stack.nl> - 2011-11-23 10:57 +0000
                      Re: Which lean C compiler for 32-bit OS development Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-24 01:31 -0800
                Re: Which lean C compiler for 32-bit OS development "BartC" <bc@freeuk.com> - 2011-11-23 10:58 +0000
                Re: Which lean C compiler for 32-bit OS development Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-24 00:26 -0800
      Re: Which lean C compiler for 32-bit OS development Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-14 01:33 -0800
        Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-11-14 17:13 +0000
          Re: Which lean C compiler for 32-bit OS development Joe Wright <joewwright@comcast.net> - 2011-11-14 14:36 -0500
          Re: Which lean C compiler for 32-bit OS development Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-15 00:56 -0800
    Re: Which lean C compiler for 32-bit OS development Nobody <nobody@nowhere.com> - 2011-11-13 02:59 +0000
      Re: Which lean C compiler for 32-bit OS development Joe Wright <joewwright@comcast.net> - 2011-11-12 22:13 -0500
        Re: Which lean C compiler for 32-bit OS development "ankh" <star67@venus.gov> - 2011-11-13 00:03 -0600
        Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-14 21:55 +0100
          Re: Which lean C compiler for 32-bit OS development Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-15 00:56 -0800
          Re: Which lean C compiler for 32-bit OS development ImpalerCore <jadill33@gmail.com> - 2011-11-15 07:05 -0800
            Re: Which lean C compiler for 32-bit OS development Keith Thompson <kst-u@mib.org> - 2011-11-15 14:42 -0800
              Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-16 00:17 +0100
              Re: Which lean C compiler for 32-bit OS development ImpalerCore <jadill33@gmail.com> - 2011-11-15 17:50 -0800
      Re: Which lean C compiler for 32-bit OS development BGB <cr88192@hotmail.com> - 2011-11-12 20:38 -0700
        Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-11-13 00:00 -0800
          Re: Which lean C compiler for 32-bit OS development BGB <cr88192@hotmail.com> - 2011-11-13 01:23 -0700
          Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-11-13 09:10 +0000
            Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-13 10:33 +0100
              Re: Which lean C compiler for 32-bit OS development Ian Collins <ian-news@hotmail.com> - 2011-11-13 23:03 +1300
                Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-11-13 11:17 +0100
            Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-10 11:29 -0800
              Re: Which lean C compiler for 32-bit OS development Ian Collins <ian-news@hotmail.com> - 2011-12-11 09:57 +1300
                Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-10 14:26 -0800
                  Re: Which lean C compiler for 32-bit OS development Ian Collins <ian-news@hotmail.com> - 2011-12-11 11:38 +1300
                    Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-10 16:01 -0800
                      Re: Which lean C compiler for 32-bit OS development Ian Collins <ian-news@hotmail.com> - 2011-12-11 13:18 +1300
                        Re: Which lean C compiler for 32-bit OS development Robert Wessel <robertwessel2@yahoo.com> - 2011-12-10 22:50 -0600
                        Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-12 11:25 -0800
                      Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-11 03:45 +0000
                        Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-12 12:06 -0800
                          Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-12 20:02 +0000
                            Re: Which lean C compiler for 32-bit OS development John Tsiombikas <nuclear@member.fsf.org> - 2011-12-13 06:28 +0000
                              Re: Which lean C compiler for 32-bit OS development Robert Wessel <robertwessel2@yahoo.com> - 2011-12-13 00:32 -0600
                                Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-12-13 10:57 +0100
                  Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-10 23:20 +0000
                    Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-12 12:38 -0800
                      Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-12 20:15 +0000
                        Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-12 13:51 -0800
                          Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-12 22:32 +0000
                            Re: Which lean C compiler for 32-bit OS development John Tsiombikas <nuclear@member.fsf.org> - 2011-12-13 06:40 +0000
                              Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-13 09:19 +0000
                              Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-17 00:52 -0800
                            Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-14 13:00 -0800
                              Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-14 21:53 +0000
                              Re: Which lean C compiler for 32-bit OS development Ian Collins <ian-news@hotmail.com> - 2011-12-15 11:18 +1300
                                Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-15 11:16 -0800
                                  Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-15 19:35 +0000
                                    Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-15 13:03 -0800
                                    Re: Which lean C compiler for 32-bit OS development Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-12-16 03:55 -0800
                                      Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-16 19:50 +0000
                      Re: Which lean C compiler for 32-bit OS development Robert Wessel <robertwessel2@yahoo.com> - 2011-12-12 16:54 -0600
                      Re: Which lean C compiler for 32-bit OS development Ian Collins <ian-news@hotmail.com> - 2011-12-13 12:03 +1300
                        Re: Which lean C compiler for 32-bit OS development Robert Wessel <robertwessel2@yahoo.com> - 2011-12-12 17:19 -0600
                          Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-15 11:52 -0800
                      Re: Which lean C compiler for 32-bit OS development Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-12-12 18:34 -0500
                        Re: Which lean C compiler for 32-bit OS development "io_x" <a@b.c.invalid> - 2011-12-13 09:43 +0100
                        Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-15 11:33 -0800
              Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-10 21:13 +0000
                Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-10 15:10 -0800
                  Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-10 23:31 +0000
                  Re: Which lean C compiler for 32-bit OS development jacob navia <jacob@spamsink.net> - 2011-12-11 01:57 +0100
                    Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-12 11:46 -0800
                      Re: Which lean C compiler for 32-bit OS development James Kuyper <jameskuyper@verizon.net> - 2011-12-12 15:23 -0500
                        Re: Which lean C compiler for 32-bit OS development Seebs <usenet-nospam@seebs.net> - 2011-12-12 20:02 +0000
                        Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-12 14:00 -0800
                          Re: Which lean C compiler for 32-bit OS development James Kuyper <jameskuyper@verizon.net> - 2011-12-12 17:24 -0500
                        Re: Which lean C compiler for 32-bit OS development Robert Wessel <robertwessel2@yahoo.com> - 2011-12-12 17:06 -0600
                          Re: Which lean C compiler for 32-bit OS development James Kuyper <jameskuyper@verizon.net> - 2011-12-12 18:16 -0500
              Re: Which lean C compiler for 32-bit OS development James Kuyper <jameskuyper@verizon.net> - 2011-12-11 09:03 -0500
                Re: Which lean C compiler for 32-bit OS development 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-11 08:57 -0800
                Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-12 12:11 -0800
                  Re: Which lean C compiler for 32-bit OS development Keith Thompson <kst-u@mib.org> - 2011-12-12 14:25 -0800
                    Re: Which lean C compiler for 32-bit OS development James Harris <james.harris.1@googlemail.com> - 2011-12-14 13:44 -0800
    Re: Which lean C compiler for 32-bit OS development "ankh" <star67@venus.gov> - 2011-11-12 22:42 -0600

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#14542

On 2011-12-12, Seebs <usenet-nospam@seebs.net> wrote:
> On 2011-12-12, James Harris <james.harris.1@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/

[toc] | [prev] | [next] | [standalone]

#14543

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

>On 2011-12-12, Seebs <usenet-nospam@seebs.net> wrote:
>> On 2011-12-12, James Harris <james.harris.1@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.


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.

[toc] | [prev] | [next] | [standalone]

#14553

Le 13/12/11 07:32, Robert Wessel a écrit :
> On 13 Dec 2011 06:28:47 GMT, John Tsiombikas<nuclear@member.fsf.org>
> wrote:
>
>> On 2011-12-12, Seebs<usenet-nospam@seebs.net>  wrote:
>>> On 2011-12-12, James Harris<james.harris.1@googlemail.com>  wrote:
>>> 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.
>
>
> 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.

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

[toc] | [prev] | [next] | [standalone]

#14464

On 2011-12-10, James Harris <james.harris.1@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.

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

[toc] | [prev] | [next] | [standalone]

#14514

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

[toc] | [prev] | [next] | [standalone]

#14517

On 2011-12-12, James Harris <james.harris.1@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.

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

[toc] | [prev] | [next] | [standalone]

#14521

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.

...

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

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

[toc] | [prev] | [next] | [standalone]

#14526

On 2011-12-12, James Harris <james.harris.1@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.

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

[toc] | [prev] | [next] | [standalone]

#14544

On 2011-12-12, Seebs <usenet-nospam@seebs.net> wrote:
> On 2011-12-12, James Harris <james.harris.1@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.


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

[toc] | [prev] | [next] | [standalone]

#14552

On 2011-12-13, John Tsiombikas <nuclear@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.

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

[toc] | [prev] | [next] | [standalone]

#14655

On Dec 13, 6:40 am, John Tsiombikas <nucl...@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.

It has been fun responding to the challenges. I think like many of us
I don't mind at all dealing with objections as long as I feel people
are hearing what I say, er, what I write..., er reading what I ...,
well, you know what I mean. Fortunately, the objections and comments,
while negative, have all been on topic and making intelligent points.

The passionate nature of the objections is a bit of a mystery
especially since no-one knows any of the details of what I have
planned. I deliberately haven't explained them - mainly because they
cannot be taken in isolation. However, I have mentioned *why* I have a
need for something new and that it doesn't preclude interfacing with
existing systems.

So why the objections? Some possible reasons:

1. FUD.

2. Misoneism. http://en.wiktionary.org/wiki/misoneism

3. Inertia. (The current systems were alright for my father....)

4. Ignorance. Not knowing the reason for something new (and not
asking).

5. Accustomisation with seeing cranky ideas.

I think the last is most likely. This is Usenet, after all.

James

[toc] | [prev] | [next] | [standalone]

#14606

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

[toc] | [prev] | [next] | [standalone]

#14609

On 2011-12-14, James Harris <james.harris.1@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.

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

[toc] | [prev] | [next] | [standalone]

#14611

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

[toc] | [prev] | [next] | [standalone]

#14632

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

[toc] | [prev] | [next] | [standalone]

#14634

On 2011-12-15, James Harris <james.harris.1@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.  :)

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

[toc] | [prev] | [next] | [standalone]

#14638

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

[toc] | [prev] | [next] | [standalone]

#14648

On Dec 15, 9:35 pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> 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.  :)
>
You write an applications level program to, say dynamically update a
list of references in a word processing document. It updates 2%
faster. Not much has been achieved.

But at the systems level, if you make all programs on the computer 2%
faster, that's worth a great deal. Not by itself, but cumulatively
with other improvements, 2% here and there has a real impact on
performance.
--
MiniBasic - how to write a script interpreter
http://www.malcolmmclean.site11.com/www

[toc] | [prev] | [next] | [standalone]

#14650

On 2011-12-16, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> On Dec 15, 9:35?pm, Seebs <usenet-nos...@seebs.net> wrote:
>> 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. ?:)

> But at the systems level, if you make all programs on the computer 2%
> faster, that's worth a great deal. Not by itself, but cumulatively
> with other improvements, 2% here and there has a real impact on
> performance.

Maybe.  But we weren't talking about 2%.  We were talking about 10% of 2%.

And at that point, it's quite possible that the side-effect costs ("we
can't upgrade to a newer gcc yet, no one's ported it to support this")
could easily exceed the nominal benefits.

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

[toc] | [prev] | [next] | [standalone]

#14527

On Mon, 12 Dec 2011 12:38:13 -0800 (PST), James Harris
<james.harris.1@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.

[toc] | [prev] | [next] | [standalone]

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web