Re: [9fans] partial-Plan9ification question

Re: [9fans] partial-Plan9ification question

[David Gordon Hogan]

[-- Attachment #1: Type: text/plain, Size: 81 bytes --]

To quote the old Basser fortunes file:

	Don't patch bad code.  Rewrite it.


[-- Attachment #2: Type: message/rfc822, Size: 2157 bytes --]

From: Rick Hohensee <humbubba@smarty.smart.net>
To: 9fans@cse.psu.edu
Subject: [9fans] partial-Plan9ification question
Date: Thu, 12 Jul 2001 18:16:00 -0400 (EDT)
Message-ID: <200107122216.SAA29875@smarty.smart.net>

Hi.
 Given a POSIXy unix, with lots of inline assembly interlaced in the C
with Gcc asm(""), consider losing all the asm("") in lieu of C-called
assembly and inlined C. This presents a factoring problem for header files
and so on relative to unix. Given also that Plan 9's header structure is
the best for languages like C, and given that we want that Plan9ism, but
not the cross-compile facilities any time soon, how would you restructure
the sources? (I'll be presuming my whole world is one cpu.) I know I'll
need a cpu.S, a cpu.o, but then things get variable. I'll also probably be
doing ld-related #pragmas, and maybe a mk or a proto-mk in sh, but I don't
know that that pertains to the above issue if I just assume one CPU. Care
to comment, maestros?

Rick Hohensee
		www.clienux.com

Re: [9fans] partial-Plan9ification question

[Rick Hohensee]

>
> This is a multi-part message in MIME format.
> --upas-xfrfzcfawtgicfgpshiwkxvkyn
> Content-Disposition: inline
> Content-Type: text/plain; charset="US-ASCII"
> Content-Transfer-Encoding: 7bit
>
> To quote the old Basser fortunes file:
>
> 	Don't patch bad code.  Rewrite it.

Sure. I'm starting with the worst. Which is 1% of the total.

Rick Hohensee
		www.clienux.com

Re: [9fans] partial-Plan9ification question

[Douglas A. Gwyn]

David Gordon Hogan wrote:
> To quote the old Basser fortunes file:
>         Don't patch bad code.  Rewrite it.

Better yet, make those "talented kids" rewrite it.

Re: [9fans] partial-Plan9ification question

[Dan Cross]

In article <20010712220824.80D9A199C0@mail.cse.psu.edu> you write:
>To quote the old Basser fortunes file:
>
>	Don't patch bad code.  Rewrite it.

Errm, aren't you indirectly quoting Kernighan and Plauger here?  I
thought I read this in, ``The Elements of Programming Style'' once.

	- Dan C.

Re: [9fans] partial-Plan9ification question

[Boyd Roberts]

From: "Dan Cross" <cross@math.psu.edu>
> Errm, aren't you indirectly quoting Kernighan and Plauger here?  I
> thought I read this in, ``The Elements of Programming Style'' once.

nah, pure basser unix/8th ed/plan 9 mafia...

you know who you are.

[9fans] partial-Plan9ification question

[Rick Hohensee]

Hi.
 Given a POSIXy unix, with lots of inline assembly interlaced in the C
with Gcc asm(""), consider losing all the asm("") in lieu of C-called
assembly and inlined C. This presents a factoring problem for header files
and so on relative to unix. Given also that Plan 9's header structure is
the best for languages like C, and given that we want that Plan9ism, but
not the cross-compile facilities any time soon, how would you restructure
the sources? (I'll be presuming my whole world is one cpu.) I know I'll
need a cpu.S, a cpu.o, but then things get variable. I'll also probably be
doing ld-related #pragmas, and maybe a mk or a proto-mk in sh, but I don't
know that that pertains to the above issue if I just assume one CPU. Care
to comment, maestros?

Rick Hohensee
		www.clienux.com

Re: [9fans] partial-Plan9ification question

[Boyd Roberts]

From: "Rick Hohensee" <humbubba@smarty.smart.net>
>  Given a POSIXy unix, with lots of inline assembly interlaced in the C
> with Gcc asm(""), consider losing all the asm("") in lieu of C-called
> assembly and inlined C.

asm's?  who in their right mind uses those?  PUSy unix...

> This presents a factoring problem for header files
> and so on relative to unix. Given also that Plan 9's header structure is
> the best for languages like C, and given that we want that Plan9ism, but
> not the cross-compile facilities any time soon, how would you restructure
> the sources?

that is an oxymoron.

> (I'll be presuming my whole world is one cpu.)

very bad choice.  one of the big features of plan 9 is the
cross compiler stuff.  name one unix (or any other) system
that can do it.  well i'm a huge limbo fan, but that's
a virtual machine, but so what.

ever heard the expression?

    all the world's a vax

> I know I'll need a cpu.S, a cpu.o, but then things get variable. I'll
> also probably be doing ld-related #pragmas, and maybe a mk or a proto-mk
> in sh, but I don't know that that pertains to the above issue if I just
> assume one CPU. Care to comment, maestros?

one cpu?  where is the problem?  why not write in in assembler?

take a look at inferno's mash mk.

the only reasons for those hacks and cruft was back when machines
where big, expensive and slow.  sure an asm("movc3 ...");  may beat
strcpy but it will _bite_ you when you change compilers
(register allocation problem) or architectures.

like henry spencer once said:

    that little tin god efficiency

Re: [9fans] partial-Plan9ification question

[Rick Hohensee]

>
> From: "Rick Hohensee" <humbubba@smarty.smart.net>
> >  Given a POSIXy unix, with lots of inline assembly interlaced in the C
> > with Gcc asm(""), consider losing all the asm("") in lieu of C-called
> > assembly and inlined C.
>
> asm's?  who in their right mind uses those?  PUSy unix...

The very insanest. Talented kids.

>
> > This presents a factoring problem for header files
> > and so on relative to unix. Given also that Plan 9's header structure is
> > the best for languages like C, and given that we want that Plan9ism, but
> > not the cross-compile facilities any time soon, how would you restructure
> > the sources?
>
> that is an oxymoron.

OK, header files structure like Plan 9 without the cross-compiler
capabilities is the oxymoron. So what's left? What's the Plan 9
subset? What's Plan 9 for a one-cpu world? That's what I want. I'm not
Bell Labs.

>
> > (I'll be presuming my whole world is one cpu.)
>
> very bad choice.  one of the big features of plan 9 is the
> cross compiler stuff.  name one unix (or any other) system
> that can do it.  well i'm a huge limbo fan, but that's
> a virtual machine, but so what.
>

I can't name any such unix. I also don't know any unix user off-hand that
has ever cross-compiled anything. It's not something that happens a lot.
The whole joint gets ported by some major effort, and then all the people
on a particular platform install that. Plan 9 heterogeny is great, but
it's way ahead of my needs.

> ever heard the expression?
>
>     all the world's a vax
>

No, I haven't. Ever heard the expression "If you've seen one Forth, you've
seen one Forth."

i.e. I miss your point.

> > I know I'll need a cpu.S, a cpu.o, but then things get variable. I'll
> > also probably be doing ld-related #pragmas, and maybe a mk or a proto-mk
> > in sh, but I don't know that that pertains to the above issue if I just
> > assume one CPU. Care to comment, maestros?
>
> one cpu?  where is the problem?  why not write in in assembler?
>

So the next guy can write it for another arch in finite time.

> take a look at inferno's mash mk.
>

Will do, if public source.

> the only reasons for those hacks and cruft was back when machines
> where big, expensive and slow.  sure an asm("movc3 ...");  may beat
> strcpy but it will _bite_ you when you change compilers
> (register allocation problem) or architectures.

It's biting me between Gcc 2.5 and 3.0, (5 year span?) and is so complex
as to be likely to recur.

>
> like henry spencer once said:
>
>     that little tin god efficiency

It's not even efficiency so much. You can use some obscure deformed
looping construct for some fossil CPU (x86) in linked assembly with a
function call interface that ports reasonably and the hit will not be
noticable if your loops aren't all tiny. For the short ones involving
control registers and other oddities, performance is usually irrelevant.
You're in a trap handler or something. There are exceptions, where you're
gonna pay, but thinking more bottom-up also leads to maximal use of better
methods otherwise available. Inlined C is pretty snappy if you can use it,
and if you have to then you do look for those opportunities.

Speaking of that, what's the calling convention of 8c? Gcc is, I think
caller saves, args are pushed last to first, return value in eax on x86.

Rick Hohensee
		www.clienux.com

Re: [9fans] partial-Plan9ification question

[forsyth]

>>Speaking of that, what's the calling convention of 8c? Gcc is, I think
>>caller saves, args are pushed last to first, return value in eax on x86.

the plan 9 compilers are strictly caller-saves, for all architectures.  other details vary.
on some platforms, a few useful constants are reserved in floating-point registers.

gcc varies between architectures, and even from platform to platform,
but i think even on the x86 with hardly any registers, some registers are callee-saved.

Re: [9fans] partial-Plan9ification question

[Mike Haertel]

>the plan 9 compilers are strictly caller-saves, for all architectures.  other details vary.
>on some platforms, a few useful constants are reserved in floating-point registers.
>
>gcc varies between architectures, and even from platform to platform,
>but i think even on the x86 with hardly any registers, some registers are callee-saved.

On x86 unix systems, eax, edx, and ecx are callee-saves, and the rest
are caller-saves.  eax and edx are used for return values.

For AMD's forthcoming x86-64, the gcc folks actually had the luxury
of being able to invent their own convention, rather than having
to follow a convention dictated to them by existing tools and
libraries.  They did some studies and ended up choosing about half
and half caller and callee saves.  I think there are slightly more
caller-saves registers.  They also went to some effort to pass a
few arguments in registers.  The down side is their conventions
appear hairy.

Just to keep this from drifting off Plan 9 entirely: any luck on
the 8c sign extension bug?

Re: [9fans] partial-Plan9ification question

[David Gordon Hogan]

> gcc varies between architectures, and even from platform to platform,
> but i think even on the x86 with hardly any registers, some registers are callee-saved.

ebx, esi and edi are callee save under GCC.  ebp is the frame pointer, so
that one gets preserved too (I've no idea what happens if you compile with
-fomit-frame-pointer).

This means that in the Plan 9 port of GCC, the system call wrappers
have to push these four registers, then push copies of all the arguments...

Re: [9fans] partial-Plan9ification question

[Rick Hohensee]

>
> > gcc varies between architectures, and even from platform to platform,
> > but i think even on the x86 with hardly any registers, some registers are callee-saved.
>
> ebx, esi and edi are callee save under GCC.  ebp is the frame pointer, so
> that one gets preserved too (I've no idea what happens if you compile with
> -fomit-frame-pointer).

I've never had -fomit-frame-pointer break anything. I think maybe it's an
extranaeity for Pascal. Or for if you suddenly decide your GNU C is
Pascal on the fly. i.e. I don't get why it's not the default.

Thanks to replyers fore and aft of this post. Looks like my headers
question is all on me.

Rick Hohensee

>
> This means that in the Plan 9 port of GCC, the system call wrappers
> have to push these four registers, then push copies of all the arguments...
>

Re: [9fans] partial-Plan9ification question

[David Gordon Hogan]

> On x86 unix systems, eax, edx, and ecx are callee-saves, and the rest
> are caller-saves.  eax and edx are used for return values.

If eax and edx are callee-save, how can they be return values?  :-P

Re: [9fans] partial-Plan9ification question

[brucee]

please consider no ifdefs ever.  and assembly language
only in vital library functions.  sure we need
/sys/src/libc/arm/memmove.s but there is
/sys/src/libc/port/memmove.c

your code may then be understandable and maintainable.

#ifndef throw_up
#define throw_up(p)	chunder(p)
#endif

is really rather silly but prevalent.

brucee

Re: [9fans] partial-Plan9ification question

[Rick Hohensee]

>
> please consider no ifdefs ever.  and assembly language
> only in vital library functions.  sure we need
> /sys/src/libc/arm/memmove.s but there is
> /sys/src/libc/port/memmove.c
>
> your code may then be understandable and maintainable.
>
> #ifndef throw_up
> #define throw_up(p)	chunder(p)
> #endif
>
> is really rather silly but prevalent.
>
> brucee
>

The existing unix I'm talking about (Linux 1.2.13) won't turn into Plan 9
style source overnight. I agree though. One thing I think I can get from
here is the only-include-me-once condoms, which I have some scripting done
for. That used to annoy the fire out of me in Amiga JForth. FORTH, fer
cryin out loud. (JForth was quite elegant mostly, BTW. "A
once-in-a-paradigm thing").

Rick Hohensee
		www.clienux.com

Re: [9fans] partial-Plan9ification question

[David Gordon Hogan]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

> I've never had -fomit-frame-pointer break anything. I think maybe it's an
> extranaeity for Pascal. Or for if you suddenly decide your GNU C is
> Pascal on the fly. i.e. I don't get why it's not the default.

I'ver never used it, so I've never had it break anything either.

My point was that I don't know whether ebp is callee-saved if
you use this option, and frankly I don't give a damn.


[-- Attachment #2: Type: message/rfc822, Size: 2304 bytes --]

From: Rick Hohensee <humbubba@smarty.smart.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] partial-Plan9ification question
Date: Fri, 13 Jul 2001 14:26:35 -0400 (EDT)
Message-ID: <200107131826.OAA09484@smarty.smart.net>

>
> > gcc varies between architectures, and even from platform to platform,
> > but i think even on the x86 with hardly any registers, some registers are callee-saved.
>
> ebx, esi and edi are callee save under GCC.  ebp is the frame pointer, so
> that one gets preserved too (I've no idea what happens if you compile with
> -fomit-frame-pointer).

I've never had -fomit-frame-pointer break anything. I think maybe it's an
extranaeity for Pascal. Or for if you suddenly decide your GNU C is
Pascal on the fly. i.e. I don't get why it's not the default.

Thanks to replyers fore and aft of this post. Looks like my headers
question is all on me.

Rick Hohensee

>
> This means that in the Plan 9 port of GCC, the system call wrappers
> have to push these four registers, then push copies of all the arguments...
>

Re: [9fans] partial-Plan9ification question

[David Gordon Hogan]

> Errm, aren't you indirectly quoting Kernighan and Plauger here?  I
> thought I read this in, ``The Elements of Programming Style'' once.

Web search says...  yep!

The fortune wasn't attributed.

The moral is, always do a web search before quoting someone :-)