Some thoughts on paflof.

[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

Stefan Reinauer wrote:
> 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...

Hello Stefan,

i am now making the 4th attempt to ask, if i can help with the OpenBios
project. I never got _any_ response, so i am asking, if anybody is
hearing me ?????????????

Regards

Klaus

[e-mail]

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Stefan Reinauer]

* Klaus Seegebarth  [020612 12:42]:
> Stefan Reinauer wrote:
> > 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...
>
> Hello Stefan,
>
> i am now making the 4th attempt to ask, if i can help with the OpenBios
> project. I never got _any_ response, so i am asking, if anybody is
> hearing me ?????????????

Sorry, seems something went wrong with me here.

If you (or anyone else) wants to help, you can choose from quite a lot
of different things to get started.

Some of the open areas are:
 * We need a PCI bus driver pretty
 * having an FCode evaluator for paflof (written in Forth)
   would be nice
 * device interface is completely unimplemented
 * lots of high level words (i.e. see) are missing

You find some additional status information on the Roadmap page
http://www.freiburg.linux.de/OpenBIOS/status/roadmap.html

The CVS tree contains a directory called fcode/ which contains some
implementations of forth words already. If you find something that is
still missing in there and in paflof, just send a mail to this list
that you want to implement it.

Check the Docs page for the IEEE specs before you start implementing.

Feel free to ask any further questions.

Stefan

Stefan Reinauer wrote:
> If you (or anyone else) wants to help, you can choose from quite a lot
> of different things to get started.

[snip...snip]
> The CVS tree contains a directory called fcode/ which contains some
> implementations of forth words already. If you find something that is
> still missing in there and in paflof, just send a mail to this list
> that you want to implement it.
> Check the Docs page for the IEEE specs before you start implementing.
>
> Feel free to ask any further questions.

Thanks for your answer. 
Atleast my postings do not go to the nulldevice :-)

As i have only small knowledge of Linux and am totally unfamiliar
with CVS, maybe i am too stupid to be helpful. OTOH i am working 
with various flavours of Forth and i am highly interested to use
OpenBios on embeddded controllers as base of my homebrewn RTOS.
I downloaded the paflof-tarball, but did not really understand
it, mainly because i do not know PERL. The C-Code was a bit too
complicated to be understood in half an hour, but i think i can
manage it during half a day.

Therefore my question: Is there some global description available,
which describes the design of the whole thing, or do i need to
understand everything from the sourcecode ?

If there is no such description, i am interested to write it, 
just to be sure i have understood everything right. Does it 
make sense to contact Segher Boessenkool directly ?

Thanks for your patience

Klaus

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Tobias Diedrich]

Klaus Seegebarth wrote:
> Thanks for your answer. 
> Atleast my postings do not go to the nulldevice :-)

Except for some spam i've seen zero postings between
03/08 and 05/22 so maybe there was a problem with the ML...

[Segher Boessenkool]

> If there is no such description, i am interested to write it,
> just to be sure i have understood everything right. Does it
> make sense to contact Segher Boessenkool directly ?

Just mail the list :)

About the Paflof inner interpreter:

1) It's plain old simple indirect threading;
2) It uses gcc's computed-goto construct; i.e., goto &&label,
   or actually, goto *something, where *something = &&label;
3) The perl thingy just takes something that looks a lot like
   Forth, and (together with some C macros) transforms it into
   a C array that represents the initial dictionary.

The C code isn't as readable as possible, but that's due to

a) C doesn't allow to cast pointers to integers v.v. etc. without
   going through a union;
b) performance is king ;)

Any more questions?  Please ask :)

Segher

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

Segher Boessenkool wrote:

[snip...snip]
> About the Paflof inner interpreter:
> It's plain old simple indirect threading;

[snip...snip]
> Any more questions?  Please ask :)

Thanks for your kind answers. I suppose i do not understand some 
fundamental design decisions.
> From my knowledge about OpenFirmware i remember, that OF is a

token threaded ANS-Forth with some extensions for the device-tree
and a number of tokens (roundabout 300?) have a predefined value.

So i would expect OpenBios to use token threading instead of 
indirect threading. If OpenBios wants strict compatibility with 
IEEE 1275, isn´t this necessary ?  The tokenizer/detokenizer for
C-Code is a nice feature for all those, who are frightened by Forth,
but isn´t it just a convenient add-on, while the token threaded Forth
is the heart of the whole thing ?

What is wrong with my thoughts ?

Regards

Klaus

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Patrick Mauritz]

On Thu, Jun 13, 2002 at 12:52:19PM +0200, Klaus Seegebarth wrote:
> From my knowledge about OpenFirmware i remember, that OF is a 
> token threaded ANS-Forth with some extensions for the device-tree
> and a number of tokens (roundabout 300?) have a predefined value.
> What is wrong with my thoughts ?

maybe that the structure of the dictionary is an implementation detail
in _every_ Forth "standard"? so it's not important if we're using indirect
threaded, direct threaded or anything else - there could even be an OF
implementation that compiles to real binary code, but that's not feasible
for a multiplatform project...

so where's the problem?

patrick mauritz

[Stefan Reinauer]

* Klaus Seegebarth  [020613 12:52]:
> From my knowledge about OpenFirmware i remember, that OF is a 
> token threaded ANS-Forth with some extensions for the device-tree
> and a number of tokens (roundabout 300?) have a predefined value.

about 360 words are defined with existing fcode token.
> So i would expect OpenBios to use token threading instead of 
> indirect threading. If OpenBios wants strict compatibility with 
> IEEE 1275, isn?t this necessary ?

There was a token threading approach that I wrote last year but it
showed up to be inflexible and it's a lot easier to have a sane forth
kernel with a seperated FCode evaluator written in Forth (Which is
similar to the normal interpreter, just reading tokens from a stream
instead of Forth source).
There are quite some words that dont have an FCode token, and those
cannot be supported without exceptions in a token threaded
implementation.
> The tokenizer/detokenizer for C-Code is a nice feature for all those, 
> who are frightened by Forth, but isn?t it just a convenient add-on, 
> while the token threaded Forth is the heart of the whole thing ?

It's actually just a Forth tokenizer/detokenizer _written_ in C. It does
not allow you to write C code which is translated to bytecode. There
have been some efforts in this area, but it probably does not make sense
to spend a lot of developers' resources while not having the base system
working. It's a non trivial problem generating effective Forth Code from
C source due to Forth's stack based nature. There are some papers
available on optimizing stack machines, but I am not into this..

Best regards,
  Stefan Reinauer

Stefan Reinauer wrote:
>

[snip...snip]
> There was a token threading approach that I wrote last year but it
> showed up to be inflexible and it's a lot easier to have a sane forth
> kernel with a seperated FCode evaluator written in Forth ...

Thanks for the enlightenment, now i begin to understand :-)

Regards

Klaus

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Segher Boessenkool]

> Thanks for your kind answers. I suppose i do not understand some
> fundamental design decisions.

So please ask :)  I (think I) have good reasons for all these
design decisions... :)
> From my knowledge about OpenFirmware i remember, that OF is a
> token threaded ANS-Forth with some extensions for the device-tree
> and a number of tokens (roundabout 300?) have a predefined value.

There's no such requirement in the OF spec.

Some (almost all?) OF implementations are token threaded; they use
FCode tokens as Forth tokens.  This is a severe restriction, as this
allows us to build only a few thousand user words; also, it only
complicates things, it doesn't simplify them.

Segher

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Segher Boessenkool]

> maybe that the structure of the dictionary is an implementation detail
> in _every_ Forth "standard"? so it's not important if we're using indirect

forth79 (and/or forth83) requires some certain dictionary structure...
> threaded, direct threaded or anything else - there could even be an OF
> implementation that compiles to real binary code, but that's not feasible
> for a multiplatform project...

It's feasible, just not easy, and not all that useful either (bigger _and_
slower code --> not a good idea ;) )

Segher

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Segher Boessenkool]

> There are quite some words that dont have an FCode token, and those
> cannot be supported without exceptions in a token threaded
> implementation.

We're free to assign those an FCode number of our own.  We'd quickly
run out of numbers, though ;)

Segher

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

Hello Segher, You wrote:

[snip...snip]
> > threaded, direct threaded or anything else - there could even be an OF
> > implementation that compiles to real binary code, but that's not feasible
> > for a multiplatform project...
>
> It's feasible, just not easy, and not all that useful either (bigger _and_
> slower code --> not a good idea ;) )

AFAIR from the discussions in the early nineties, OF should work similar 
to JAVA: either interpret the bytecode (slow/small/simple) or compile 
to native code (fast/big/complicated).

Have a look to MPEs VFX-compilers, they are doing the latter for Forth 
and i am rather sure, that the same _can_ be done for FCode.

and in another posting:
> I (think I) have good reasons for all these design decisions...

I never had any doubts about it. Its just a fact, that i am
so stupid, that i needed some additional info to understand :-)

Regards

Klaus

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..