OpenBIOS June 2002

openbios@openbios.org

13 participants
25 discussions

Re: [OpenBIOS] Mailing list policy change
by Christopher Smith 12 Jun '02

12 Jun '02

i would have thought that was a good idea long ago. From: Stefan Reinauer <stepan(a)suse.de> Reply-To: openbios(a)freiburg.linux.de To: openbios(a)elvis.informatik.uni-freiburg.de Subject: [OpenBIOS] Mailing list policy change Date: Wed, 12 Jun 2002 13:19:55 +0200 Hi, Due to raising spam amounts I changed the ML policy to only allow list subscribers to post to the list directly. 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.. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com - 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..

1 0

Paflof with case insensitive dictionary lookups.
by Stefan Reinauer 12 Jun '02

12 Jun '02

Hi,.. as described in one of my last mails, case insensitive number parsing and dictionary lookups are needed for IEEE compliance. I made a little patch to Paflof, that does this. As Segher suggested, I created a word COMP-NOCASE, which is used by $FIND instead of the case sensitive COMP word. It uses UPC to uppercase the values while comparing. Additionally I changed DIGIT to uppercase a digit before comparing it to A-F so deadbeef is now a valid hex value, like DEADBEEF is. This should be checked in asap. 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)

1 0

Mailing list policy change
by Stefan Reinauer 12 Jun '02

12 Jun '02

Hi, Due to raising spam amounts I changed the ML policy to only allow list subscribers to post to the list directly. 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..

1 0

�°ӷ~�줽�ǥX��
by hcxc5_2gk1525＠allianz.de 10 Jun '02

10 Jun '02

********************** ¯Â°Ó·~¿ì€œ«Ç¥X¯² ********************** ±MªùªA°È°Ó¥Î¿ì€œ«Ç€§©Ó¯²€H¡C ¥x¥_ŠUµ¥¯Å°Ó¥Î¿ì€œ«Ç®×¥ó¡AŸAŠXŠUºØ°Ó·~»ÝšD¡I¡I §ÚÌŸÖŠ³ºZ³qªºžê°T¡BŠ³«ÜŠh¥ß§Yn¥X¯²ªº¿ì€œ«Ç¡A¥¿µ¥«ÝµÛ±zªº¬D¿ï¡A €@©wn¬°±z§äšì€@³B³ÌŸAŠX±z¹ê²{±z¶¯¹Ï§§§Óªº³õ©Ò¡I¡I¡I¡I Á|šÒŠp€U¡G °Ï°ì¡G €jŠw°Ï¡G €¯·Ržô¡BŽ°€Æ«n¡B¥_žô 50-300©W¡]¯²ª÷1200-2500€ž¡^¡B ¯Â¿ì®ð¬£€jŒÓ¡A²{ŠšŠÊžUžËæC¡]§K³»Åýª÷¡^¡B °š€W¥išÏ¥Î «Hžq°Ï¡G «Hžqžô€@¡B€G¡B€T¡B¥|¡B€¬q¡C 30-500©W¡]1200-2100€ž¡^ ¥þ·s®ð¬£€jŒÓ¡Bªñ±¶¹B¯ž€f¡B¥æ³q€è«K ¡]¯²ª÷ŠX²z¡B¥i±Ä³»ù¡^ ªQ€s°Ï¡G «nšÊªFžô€T¡B¥|¡B€¡B¬q 30-450©W¡]¯²ª÷1000-1800€ž¡^ ®ð¬£¡BŽºÆ[µŽšÎ €€€s°Ï¡G ªQŠ¿žô¡BªøŠwªFžô¡A€€€s¥_žô 70¢w400©W¡]¯²ª÷1000-2200€ž¡^ ¯Â¿ì¡B²{Š³žËæC Šè °Ï¡G ©Ÿ§µŠèžô¡BÀ]«ežô¡B©ÓŒwžô¡B¿Å¶§žô 50-500©W ŠÊžUžËæC¡B«K©y¥X¯²¡]Åwªï¬Ý«Î¡^ €ºŽò°Ï¡G «¹º°Ï 80-500©W1300€ž°_¡CœÐ§âŽ€š}Ÿ÷ ¥þ·s®ð¬£€jŒÓ¡B²{Š³žËæC¡B°š€W¥išÏ¥Î ªA°È²Ä€@¡A«~œè«OÃÒ¡CÅwªï¬¢žß. ·ç°T€£°Ê²£ °Ó¥ò³¡ Ápµž€H¡G³³€p©j ·q€W TeL¡]¥Nªíž¹¡^¡G 02-27492314 Šæ°Ê¹qžÜ¡G0937063831 ±zªºº¡·N¡A¬O§ÚÌªºŠšŽN¡I¡I¡I¡I - 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..

1 0

Re: [OpenBIOS] Defining ." and "
by Parag Patel 08 Jun '02

08 Jun '02

In message <3D020539.41212D60(a)chello.nl>, Segher Boessenkool writes: > >Where does it say it requires two? I can't find no reference to this in >the 1275 spec. The ANS, on the other hand, requires only one, and even >then only *if* you implement S" in interpreting state. Page 102 (A.2 Specification) for " and page 178 for s": "At least two temporary buffers, used alternately, shall be provided." BTW, in implementing the spec, I found I had to read each word's descriptions in detail as there's a lot of small stuff like this tucked away in the bowels of the spec. -- Parag - 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..

1 0

Re: [OpenBIOS] Defining ." and "
by Parag Patel 08 Jun '02

08 Jun '02

In message <3D0188D6.5999ED4B(a)chello.nl>, Segher Boessenkool writes: > >1) garbage collect. ouch. >2) in dictionary or similar --> never freed >3) in "string buffers" -- either 1 or 2, but both problems >less severe. 3.5) A fixed number of static fixed-length buffers that are treated as a ring of least-recently-used buffers. The Open Firmware spec requires at least two. We typically use two buffers for " and another two for s" just to make sure that they don't step on each other. The idea is that since only two are required by the spec, all development code should be able to run with at least two, and thus increasing the number later or for a specific port won't cause portability problems (as going the other way would). -- Parag - 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..

3 2

Defining ." and "
by Stefan Reinauer 08 Jun '02

08 Jun '02

Hi,.. I tried the following 2 definitions: HEX 0 > : " 22 PARSE ; IMMEDIATE ok 0 > : ." 22 PARSE TYPE ; IMMEDIATE ok Now I try 0 > ." test" test ok 0 > which works fine. So does 0 > " test" TYPE test ok The following fails as the string is overwritten: 0 > " test" ok 2 > TYPE PEst ok I could not find the reason by quickly looking into it. Any ideas? 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..

3 5

[Fwd: Re: [OpenBIOS] patch: machine dependent config]
by Segher Boessenkool 07 Jun '02

07 Jun '02

> > > Just a dumb idea, could we rewrite the preprocessing and testing > > > completely in C? I know that there are a lot of issues with perl on > > > > Nope, cpp can't do all that's necessary. Btw, once we have a working > > Forth compiler, we can use that to bootstrap itself :) > > You're talking about forth -> binary translation? That is not what we > want, I guess. Can you explain? There's three ways to represent a program: 1) Forth source 2) Forth dictionary (binary) 3) Forth dictionary/source (FCode) 3) is limited, but cross-platform; it's the prefered way for device manufacturers to distribute drivers, but there's no reason to implement our internal stuff with FCode. 2) is okay, but machine-specific. 1) is our prefered form. But that leads to a problem: the Forth compiler itself is written in Forth. So the "initial dictionary" will have to be distributed as 2). That's exactly what ref.pl + cpp magic do: they convert "pseudo-forth" source (engine.in) to dictionary. Now, what I said was: when we have the Forth compiler finished, we can have the engine.in compile a engine.fs, to replace itself. > > > newer platforms, which could make it hard to get paflof running on new > > > machines, even if we already have a gcc. Ugly though. If this is > > > > Cross-compilers save the day :) > > Cross compilers is exactly where this stops working. If I cross compile > for SH1 CPUs using a crosscompiler on Intel x86, my perl nor my gcc will > never tell me whether my 'long' is 32 or 64bit on the target platform. > We probably can't even use this to check for TI mode availability Sure you can; you just can't run the target programs, but of course the compiler knows the target data sizes :) > > I hope to finish the "Forth command group" today :) > > How much work has to be done here? One or two days, plus some cleanup, but that can be done later. > How far are we from being able to > read FCode with this (i.e. use the work in the fcode/base/ directory > already done? This is the Forth compiler, not yet the FCode compiler; that one is a lot easier. > Please make sure we don't do duplicate work here. I'll try :) > " text" is the only one missing to get the mandelbrot signature, one > of my toke test programs, running. Then we can start using the example > code and really testing the Fcode layer on top. I'll implement it without things like S" blabla(0d)(0a)blabla" etc., at first. It'll be here later tonight :) Segher - 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..

1 0

Re: [OpenBIOS] patch: machine dependent config
by Stefan Reinauer 07 Jun '02

07 Jun '02

* Segher Boessenkool <segher(a)chello.nl> [020607 13:23]: > > Except we rely on compiler defines and prerequisites to get towards a > > defined build set (which probably sucks). If we have to use this > > functionality anyways, it might be interesting to look at autoconf. > > But then again we won't get rid of all perl stuff, so using autoconf > > just adds another player to the game. > > Please let's not use autotools :) Besides their implementation is a bit far from the goal (portability), autoconf and friends cause lots of trouble, not only with new platforms but also with newer versions of autoconf etc. We definitely don't want that. > > Just a dumb idea, could we rewrite the preprocessing and testing > > completely in C? I know that there are a lot of issues with perl on > > Nope, cpp can't do all that's necessary. Btw, once we have a working > Forth compiler, we can use that to bootstrap itself :) You're talking about forth -> binary translation? That is not what we want, I guess. Can you explain? > > newer platforms, which could make it hard to get paflof running on new > > machines, even if we already have a gcc. Ugly though. If this is > > Cross-compilers save the day :) Cross compilers is exactly where this stops working. If I cross compile for SH1 CPUs using a crosscompiler on Intel x86, my perl nor my gcc will never tell me whether my 'long' is 32 or 64bit on the target platform. We probably can't even use this to check for TI mode availability > I hope to finish the "Forth command group" today :) How much work has to be done here? How far are we from being able to read FCode with this (i.e. use the work in the fcode/base/ directory already done? Please make sure we don't do duplicate work here. " text" is the only one missing to get the mandelbrot signature, one of my toke test programs, running. Then we can start using the example code and really testing the Fcode layer on top. 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..

2 1

patch: machine dependent config
by Stefan Reinauer 07 Jun '02

07 Jun '02

Hi, ok, this time I redid the patch to make paflof sane on 64bit platforms in a cleaner way, using abstracted defines that are dependent on certain platform specifics. As this is platform dependent stuff which has basically nothing to do with paflof itself, I moved it to a new file: machdep.h. I moved the sanity check out of paflof.c into machdep.c, which we will probably not need to link in case we know an architecture/compiler combination is sane. We really need to make sure we are 64bit clean from the beginning so we recognize early what problems we might have to face getting paflof portable. Segher, is this ok to check in from your side? If so, please do! 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)

2 5