Ram initialization and small c.

Jeremy Jackson jerj at coplanar.net
Tue Feb 25 18:35:00 CET 2003


On Tue, 2003-02-25 at 13:09, Steve Gehlbach wrote:

> I think you have to cramp your C coding style anyway, to stay within 
> registers.  The extra scratch area does not help much, with chips such 

A compiler *made* to compile this way could help a great deal by
scheduling instructions like an RPN calculator though, so *you* don't
have to write in spaghetti code.

BUT, would C's block-scope local variables allow registers to be re-used
by different local variables, so instead of

void func (void) {
register int eax;

/* use i for one purpose */

/* use same i for something else */
}

you could do

void func (void) {
	{
		register int ramsize;
		/* use ramsize */
	}
	{
		register int cpuid;
		/* use cpuid */
	}
}

and have both end up using the same register, kind of like a union,
but still looking more like C than assembler.

> as the SiS630, only has three gp regs, little help.  You can't go around 
> declaring variables willy nilly, you run out of space (registers) no 
> matter what compiler.

But for the cases where (in the chipset or whereever) there are scratch
registers, global extern static variables that are fixed when linking,
(or define them in an assembler stub with .org or such) would allow them
to be used easily from C.
> 
> I also have been experimenting with inline gcc, and I think it works 
> pretty well and once you get the hang of it, and it _is_ easier than 
> assy.  I have re-coded the console routines, and ram setup, and spd 
> timing setup on the sis630 for C.  It is still a wip but I have tested 
> the spd setup by wrapping a real main on a live machine.
> 
> So far it is about 400 lines of C, should I attach it?  It compiles 
> without using the stack (except for a %ebp push/pop which can be deleted).

Please do.  It would be a good example of how complex the code can be 
with the register/inline constraints.

As for the frame pointer (you mean at the start of the first function),
take a look at my sample, have you tried -fomit-frame-pointer?
> 
> I can't see how a special compiler gets you enough more than gcc to be 
> worth the downside of effort and debugging.  Scratch regs vary from chip 
> to chip, and use 1.5 regs to access (pci).  You could use the %ebp and 
> %esp which is a gain of two (and maybe %es %fs etc), but I think using 
> gcc will get us there anyway.

Looking at -fcall-saved-REG it seems that %esp and %ebp may be off
limits for gcc, but the info docs are a little vague, perhaps it must be
tried to be proven one way or the other. Inline assemply may allow them
to be used, but that would almost be back where we started.

-- 
Jeremy Jackson <jerj at coplanar.net>




More information about the coreboot mailing list