Hi!
> I was just thinking about the name of this list (and I guess the name of the
> forth coming project)
>
> Well a BIOS certainly isn't Unix, but I don't see how they are at all
> related.
> I think OpenBIOS is more appropreate and sounds a bit better as well.
OpenBIOS would mean something else. OpenBIOS would mean that we
publish our specs, not that we are free. Look at sparc OpenProm.
BAD idea.
Pavel
--
I'm really pavel(a)atrey.karlin.mff.cuni.cz. Pavel
Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).
---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com
Hi!
> Could somebody point me to where I could find a list of all the BIOS
> calls? I know I've seen them before, but I am coming up blank now.
Ralf Brown's Interrupt list?
> If I'm gonna start to think about coding, I have to know what to
> code :)
Do you want to write it in assembly or in C? How are you going to deal
with 32 bit code?
--
I'm really pavel(a)atrey.karlin.mff.cuni.cz. Pavel
Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).
---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com
Hi!
> > I think we can assume pentiums at the least since only the pent
> > m/b's and above really have flashable bois's. So why not go for a pent
> > optimised compiler and maybe have someone check the asm producded <evil
> > grin>
>
> personally, i think the gnu-bios should be done in 100% assembly,
> for
I do not think so. Well, it would be cleaner to write in assembly, but
you do not want to write neither bios setup nor grub in anything else
than C. And if you stick with gcc 2.7.2, compilers are ok.
Pavel
--
I'm really pavel(a)atrey.karlin.mff.cuni.cz. Pavel
Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).
---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com
Hi!
> > Right - that's enough of the theoretical waffle. What we need is a plan. Lots
> > and lots of these projects have died out because people spent too long talking
> > about them and did bugger all work.
>
> Well it's ony been a few days.... : >
>
> > I'd like to see a _really_ primitive skeleton BIOS up and running - just
> > enough to boot Linux, with no chipset handling or anything.
>
> I was thinking about this. IMO if you put grub stage1 + 2 in the flash that
> just may be enough.
Hmm. I took a look at grub, and it is pretty ugly. I patched it quite
a bit.
--
I'm really pavel(a)atrey.karlin.mff.cuni.cz. Pavel
Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).
---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com
Hi,
I played a bit with different gcc versions on Alpha and I
noticed that when executing the FIB test from
http://home.iae.nl/users/mhx/fib.html in paflof, results
are _a lot_ slower with gcc 3.1.1 than with 2.96 (SuSE 7.1
Alpha release) Not only is the 3.1.1 binary about 20%
bigger,
it also 22% slower.
The test:
HEX
: FIB ( x -- y ) RECURSIVE
DUP 2 > IF DUP 1- RECURSE
SWAP 2- RECURSE + EXIT
THEN
DROP 1 ;
28 FIB
BYE
The results:
gcc 2.96 binary
real 1m55.642s
user 1m55.479s
sys 0m0.014s
gcc 3.1.1 binary
real 2m21.763s
user 2m21.533s
sys 0m0.027s
Where does this come from? Is the code generated by gcc 3.x really that
slow, compared to 2.96? Do we make some assumptions that might cause
this? (How badly do gotos break code flow analysis for example?)
What can we do against this? Having more prim words will speed up the
whole thing, but probably not really make it easier for the compiler to
optimize.
Comments?
Stefan..
--
The x86 isn't all that complex - it just doesn't make a lot of
sense. -- Mike Johnson, Leader of 80x86 Design at AMD
Microprocessor Report (1994)
-
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..