OpenBIOS June 2002

openbios@openbios.org

13 participants
25 discussions

$find
by Stefan Reinauer 30 Jun '02

30 Jun '02

Hi,.. I just noticed some weirdness with $find when I do 0 > s" constant" $find ok I get 3 > .s 120019b88 0 -1 ok The definition from IEEE 1275-1994 is: $find ( name-str name-len -- xt true | name-str name-len false ) Our definition seems to be wrong: col($FIND LAST @ >R 2DUP R@ COMP-WORD ?BRANCH(9) 2DROP R> DUP >XCODE SWAP CELL+ C@ TRUE EXIT R> @ ?DUP 0= ?BRANCH(-21) 2DROP FALSE) what exactly does "SWAP CELL+ C@" do? should this not just be a NIP ? according to this we would have to change COMPILE-WORD, INTERPRET-WORD, ', POSTPONE and FIND, some of which do the NIP afterwords themselfes, as far as i can see. Any 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..

2 8

Re: Paflof update
by Stefan Reinauer 30 Jun '02

30 Jun '02

* Segher Boessenkool <segher(a)chello.nl> [020623 18:15]: > > * use c style comments to not break non gcc compilers (compile > > with -ansi -pedantic) > > Try compiling it on a non-gcc compiler. It won't work. But it's a step closer. > > * implement unaligned-w@, unaligned-w!, unaligned-l@, unaligned-l! > > I'd rather have these implemented in Forth; we have too many primitives > already. I don't agree on this. Unaligned accesses are slower than the aligned versions anyways, plus we need to bloat the forth code with endianess checks where we can solve this in the preprocessor in C. I made Forth versions of these words as well, but while thinking about when you need unaligned accesses, I came to the conclusion that you probably don't want further slowdown. It's ugly that you have to break up atomicity of the access anyways. > > * use conf.pl to create types.h according to compiler capabilities > > (cross compiling possible) (cleaner version then last patch) > > I don't like it yet... What's wrong? > > * move unix host code from prim.code to unix.code > > Please leave it where it is, for now. We'll move it when we compile > stuff from source (as opposed to the current situation: from a precompiled > dictionary). Which reminds me that we also need support for multiple linked dictionaries when doing packages. Though maybe it might be enough to have multiple fcode lookup tables in the fcode evaluator? Is there any trivial way of doing this? 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 5

ANSI
by Stefan Reinauer 30 Jun '02

30 Jun '02

Hi,.. I played a bit with the paflof sources and made them compile cleanly using gcc -ansi. I had to remove the C99 specific *restricted stuff (which did not change performance at all) Second issue was to replace C++ style comments as they are not allowed in ANSI C. The patch changes any occurence to either #ifdefs if it's code or C style comments in case of real comments. I checked it against the hayes test and got the same output as with mainstream paflof. I strongly suggest to apply this patch - this would allow a lot more people to use paflof and probably get this compiled on almost any host system. Please comment on the patch. If there is no good reason against it, this is definitely the way to go. Best regards, Stefan Reinauer -- 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)

4 17

FCode Evaluator
by Stefan Reinauer 28 Jun '02

28 Jun '02

Hi.. I uploaded a first version of an FCode evaluator written in Forth to http://www.freiburg.linux.de/OpenBIOS/bin/evaluator-20020628.tar.gz Most of the fcode specific forth words are missing and, like paflof, this evaluator does not know about instances or different dictionaries It can execute simple fcode files and it knows how to define named and external colon definition words, but that's about it. There's a small readme and a little bit of example code with it. Any comments and flames are welcome. If this approach is considered ok, I will go and drop feval from the CVS and the web pages, as we are equally far (actually a lot further) with the paflof+evaluator implementation now. This should be one of the few needed steps to get OpenBIOS towards the point where it can be flashed to ROM with LinuxBIOS as IPL. 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

Re: [OpenBIOS] Re: Paflof update
by Parag Patel 28 Jun '02

28 Jun '02

>is it legal for an fcode program to overload words defined within the >lower space (i.e. 0x000-0x5ff)? Actually, yes. Look at the PCI bus binding for one example where rl! rl@ rw! and rw@ may be overridden to handle endian issues. -- 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

Re: [OpenBIOS] $find
by Parag Patel 28 Jun '02

28 Jun '02

>SEE still needs the word's name, which is ugly to get when you have >the XT only. Both SmartFirmware and Sun's Forth OpenBoot implementations will parse the word as a number and use it to lookup an XT, if the initial word lookup fails. This lets you "see" headerless words. -- 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..

2 1

Re: [OpenBIOS] Re: Paflof update
by Parag Patel 27 Jun '02

27 Jun '02

In message <20020627152137.GC799(a)suse.de>, Stefan Reinauer writes: >> >> Actually, yes. Look at the PCI bus binding for one example where rl! >> rl@ rw! and rw@ may be overridden to handle endian issues. > >Hmm. Do I get this right? In this case Dunno - I haven't actually been downloading nor looking at your code. :) A few things just sort of jog my memory for non-obvious stuff. SmartFirmware is primarily C-oriented with Forth tacked-on, so my tricks may not apply. -- 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

Paflof update
by Stefan Reinauer 24 Jun '02

24 Jun '02

Hi, some updates on paflof I made recently: * use c style comments to not break non gcc compilers (compile with -ansi -pedantic) * implement unaligned-w@, unaligned-w!, unaligned-l@, unaligned-l! * implement 2constant * fix typo in dict.source * use conf.pl to create types.h according to compiler capabilities (cross compiling possible) (cleaner version then last patch) * move unix host code from prim.code to unix.code Best regards, Stefan Reinauer -- 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 2

Some thoughts on paflof.
by Stefan Reinauer 14 Jun '02

14 Jun '02

Hi... to get things to a point where smaller projects can be split off OpenBIOS allowing easier and more wide-spread development, we should change paflof to some point where it is usable for development... Some random thoughts that are written down below. Please comment on this.. We got to get it going asap... * according to IEEE 1275 paflof needs to be able to parse words case independant. To achieve this we have to change parse word to uppercase a word before it is looked up. hex : uppercase ( char -- uppercasechar ) dup 61 7a between 20 - ; : uppercases ( addr len -- ) bounds do i c@ uppercase i c! /c +loop ; PARSE-WORD should then contain 2DUP UPPERCASES CHAR uses PARSE-WORD illegaly. it should be replaced by the expanded version of the current PARSE-WORD implementation. * paflof needs load_dictionary and dump_dictionary. for bootstrapping it will be compiled with a primword + minimal dictionary created by the preprocessor. When this is done, the words are defined in normal forth, compiled to dictionary and then the dictionary is dumped. Putting more words into preprocessor magic only bloats this part of the implementation and does not make sense from a project point of view (Several people would have to work on the same part of code, which Segher does not prefer to see anyways) * Having different implementations of load_dictionary will allow us to use either the preprocessor based dictionary or a dumped one, depending on which dictionary target file is linked. In a flashed system load_dictionary would only change the dictionary pointer to a certain address in ram or rom. * The dictionary should be position independant. This will allow to relocate it at will in the flashed bios later on. The host version of paflof should be able to load the dictionary from a plain file at any position. Some enhancements for the flashed version of paflof come to my mind, i.e. having the choice between a full blown and a backup dictionary, i.e comparable to the emergency bios part in current legacy implementations. * The prim words are part of paflof, not the dictionary, logically seen. It does not make sense to make them position independant, as this would probably hurt performance on broken architectures like x86. We need a DOPRIM to connect the prim words to the dictionary then. * Therefore paflof should be stripped down to only contain words needed for bootstrapping the next abstraction level: the forth dictionary. Regards, 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..

6 13

Re: [OpenBIOS] Some thoughts on paflof.
by Parag Patel 13 Jun '02

13 Jun '02

>a) C doesn't allow to cast pointers to integers v.v. etc. without > going through a union; That's not true unless you don't want to use type-casts. char *foo; uint bar; foo = (char*)bar; bar = (uint)foo; Gcc will warn if the sizes of "int" warn "char*" are not the same, which is easy to workaround with an additional typecast. char *foo; /* assume 32-bit pointer */ uint64 bar; foo = (char*)(uint)bar; bar = (uint64)(uint)foo; >b) performance is king ;) First make it run, then make it fast. It's a rare problem that requires the wrong results as fast as possible. :) -- 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..

2 1