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 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

#14528

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

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

#14533

On Tue, 13 Dec 2011 12:03:54 +1300, Ian Collins <ian-news@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.

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

#14635

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

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

#14534

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
esosman@ieee-dot-org.invalid

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

#14547

"Eric Sosman" <esosman@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]

>     Arthur Clarke wrote a story called "Superiority."  Read it, if
> you can find it somewhere.
>
> -- 
> Eric Sosman
> esosman@ieee-dot-org.invalid

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

#14633

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

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

#14454

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

#14461

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

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

#14465

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

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

#14468

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

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

#14508

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

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

#14513

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.

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

#14516

On 2011-12-12, James Kuyper <jameskuyper@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.

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

#14522

On Dec 12, 8:23 pm, James Kuyper <jameskuy...@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?
>
> 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.

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

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

#14523

On 12/12/2011 05:00 PM, James Harris wrote:
> On Dec 12, 8:23 pm, James Kuyper <jameskuy...@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?
>>
>> 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.
> 
> 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.

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.

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

#14529

On Mon, 12 Dec 2011 15:23:26 -0500, James Kuyper
<jameskuyper@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.

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

#14531

On 12/12/2011 06:06 PM, Robert Wessel wrote:
> On Mon, 12 Dec 2011 15:23:26 -0500, James Kuyper
> <jameskuyper@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.

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.

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

#14480

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

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

#14484

On Sunday, December 11, 2011 10:03:01 PM UTC+8, James Kuyper wrote:
> 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

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.
   

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

#14512

On Dec 11, 2:03 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> 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.

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

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

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

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

csiph-web