Subject:
|
Re: idea for firmware development
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Fri, 19 Nov 1999 18:40:50 GMT
|
Original-From:
|
Brian Connors <connorbd@{stopspam}yahoo.com>
|
Viewed:
|
601 times
|
| |
|
|
--- Vlad Dumitrescu <vladdu@nospam.hotmail.com> wrote:
> In lugnet.robotics, Sergey Udovenko writes:
> > The whole pbForht image is only ~12k!
> > Beside the size, I think the real advantage of • pbForth implementation would be
> > in extensibility.
>
> :-) I just finished an answer to Ralph on another
> thread, and it was the same
> idea that crossed my mind - if the bytecode could be
> extended, while remaining
> backward compatible, so that it allows for more
> variables and maybe a stack,
> then it would be a big improvement!
I'd be interested in seeing whether the Lego Group
readers would go for this idea....
This OpenRCX idea (you wanna give it a name, how's
that one) could go in one of two directions: either it
tracks Lego development, or it forks off something
entirely different that's compatible at a
least-common-denominator level. Those are the two
logical options, anyway, with the second being more
likely.
How about a third option?
The Scout legoasm is now officially documented, and
Kekoa Proudfoot's bytecode-decoding is public record.
Why not take a hint from the Linux community (where
several well-publicized standards, particularly FHS
(Filesystem Hierarchy Standard), have been created
effectively with no "official" standards body
involved) and create an RCX bytecode standard?
The key to extension is probably to designate an
"escape" bytecode that allows for
implementation-specific instructions. Other bytecodes
(borrowed from Scout and Cybermaster, perhaps?) can be
top-level, to support things like VLL.
Anyone like this one?
/Brian
=====
--
|
|
1 Message in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
