Re: configuration

[Erik Verbruggen]

On Sat, Nov 04, 2000 at 03:07:25PM +0900, OKUJI Yoshinori wrote:
> From: Farid Hajji <address@hidden>
> Subject: Re: configuration
> Date: Sat, 4 Nov 2000 04:27:35 +0100
> 
> > I don't understand how GCC depends on Mach. Please enlighten me.
> 
>   As I said, see the "specs" file. I don't think we need to use
> another version of linker scripts (or executable formats), so all we
> must consider is specs.

Yes, it's mostly the linker scripts, and that's mainly binutils. Both
binutils and gcc can do some platform specific stuff. An example is
clearer: the Sparc platform defines that the mul (and friends) assembler
instruction is optionally implemented in hardware. The linker (IIRC) has
to know if it exists, and if so, will replace the call to the subroutine
by a mul instruction. On the other hand, this is platform wide and as far
as I can see it doesn't have any impact on GNUMach -- it is linked and
all symbols should be resolved by then.

> >   4. libvk functions should be defined inline as far as possible for
> >      max. speed. Quid libmom?
> 
>   I don't think Thomas did consider that. But inline functions don't
> necessarily perform better than non-inline functions, because those
> increase the size of code. As you may know, there are several real
> examples for that. For example: RISC is not faster than CISC, and L4
> doesn't define two system calls for short-message IPC and long-message
> IPC. That's because more code means less cache hits. Inline functions
> are better, only if they don't increase the size of code (very much)
> and you really need to speed up code that uses them.

Indeed. As we don't build a dynamically linkable library, gcc/ld might
be able to inline routines. I'm not sure about this, but you can
probably find this in the info pages. Otherwise take the golden rule of
optimization into account: "For programmers: don't optimize. For good
programmers: don't optimize yet." If your design isn't inheritely slow,
you can always optimize later-on.

In another post, someone mentioned device drivers. Well, I said that I'd
do some work on that. Currently I'm on the point to have a gnumach
kernel that links correctly, but the multiboot_header symbol is missing.
If that is resolved, it would mean that I have a kernel with minimal
device drivers (only [EV]GA text support for boot messages). From there
I can make some changes to do the IO specific registering (IRQ, DMA and
I/O-ports). This is for x86 at the moment, but I also compile it on my
Alpha for 64-bit cleanliness checks. For real testing of the drivers on
Alpha, I'll see what finishes first: L4 on Alpha, or my personal
modified GNUMach version (thanks to Ron & Co for the CVS repository).
Sorry for (still) using GNUMach, but to me it seems more probably that
it will run on Alpha than L4. Not to annoy/insult someone, but I haven't
yet seen much work in any form done on that and I'm still not able to
build or get a working alphaL4 kernel to play with. Not that it matters
very much -- I want to make the device driver server with as little
modifications and ukernel specific as possible. So I'll switch to L4 as
soon as I have a nice working ukernel ;-)

Ok, end of yet another long rant from me,

Erik.