Re: [9fans] partial-Plan9ification question

[Rick Hohensee <humbubba@smarty.smart.net>]

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