$find
by Stefan Reinauer
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..
18 years
- 2
- 8
Re: Paflof update
by Stefan Reinauer
* 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..
18 years
- 2
- 5
ANSI
by Stefan Reinauer
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)
18 years
- 4
- 17
FCode Evaluator
by Stefan Reinauer
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..
18 years
- 1
- 0
Re: [OpenBIOS] Re: Paflof update
by Parag Patel
>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..
18 years
- 3
- 2
Re: [OpenBIOS] $find
by Parag Patel
>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..
18 years
- 2
- 1
Re: [OpenBIOS] Re: Paflof update
by Parag Patel
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..
18 years
- 1
- 0
Paflof update
by Stefan Reinauer
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)
18 years
- 2
- 2
Some thoughts on paflof.
by Stefan Reinauer
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..
18 years, 1 month
- 6
- 13
Re: [OpenBIOS] Some thoughts on paflof.
by Parag Patel
>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..
18 years, 1 month
- 2
- 1