Subject:
|
Some comments (long) (was: Something else is needed, I think...)
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 6 May 1999 00:13:11 GMT
|
Viewed:
|
871 times
|
| |
|
|
I think that what may actually be the best thing for the RCX in
terms of a new bytecode interpreter is one which is virtually a plug-in
replacement for the old one. I've been doing some extensive mulling
over the RCX internals documentation so generously provided by Kekoa,
and I would like to comment on some observations I've made and
conclusions that I've drawn.
There appear to be 193 opcodes in the existing interpreter. This
means that there are 63 unused opcodes for possible instructions. This
should be more than enough to add any extra opcodes necessary to
transcend the limitations while still being compatible with the older
bytecode.
One of the first limitations to be overcome should be the 8
subroutine limit. At least one new instruction should be added which
allows the specification of a 16 bit function address, making available
memory the restrictive aspect rather than merely subroutine count.
The existing system has 32 global variables. It seems to me that an
enhanced interpreter that did not share this limitation could still
remain completely compatible with the existing one (at the bytecode
level) if instead of variables, these are simply considered to be
registers. This way, the only instructions which need to be added to
transcend the 32 variable limit would be the few necessary to move data
between these registers and global or stack memory. Almost all other
computations can be presumed to operate just with registers, and most of
the other instructions would not have to be modified in what they could
do.
I do not believe that a compatible bytecode interpreter can feasibly
have any floating point routines built into it. Fixed point would need
to be used at the source code level. It's not that difficult to, at the
source code level, use everything multiplied by some constant factor
anyways. This also gives the flexibility of the user being able to use
whatever precision they decide is appropriate for their particular
application.
For issues of compatibility, of course, the 32 registers
("variables") must remain global to all threads. I personally don't
particularly care for this, however, and would offer the suggestion that
there be a set of registers ("variables") numbered above 32, which are
local to each task. This should be do-able because to the best of my
knowledge, an entire byte is dedicated to specifying which variable to
work with anyways, rather than just 5 bits. The number of such
registers should be reasonable but not wasteful -- I would suggest 8 as
a minimum and 32 as an absolute maximum. The presence of such registers
*IMMENSELY* simplifies the job of writing compilers that can produce
thread-safe code. (In fact, in bytecode compiled from high level
languages, you might never actually see any reference to any of the
older variables at all!)
|
|
Message has 4 Replies:
 | | Re: Some comments (long)
|
| (...) <snip> Mark and John's messages this morning look like the beginnings of two separate developments for the RCX, both of which have the potential to satisfy the needs of many who are dissatisfied with the current firmware. Hopefully both ideas (...) (25 years ago, 6-May-99, to lugnet.robotics)
| | | Re: Some comments (long)
|
| (...) I was wondering if any of these projects is thinking in providing enough flexibility that would make possible for anyone smoothly integrate new sensors with the currently supported ones? (Like Dennis Clark's RCX IRPD?) Sorry to return to this, (...) (25 years ago, 6-May-99, to lugnet.robotics)
| | | Re: Some comments (long)
|
| So to preface my comments to Mark's message, I should say that even though I point out technical problems with what he proposes, I do not mean to imply that these technical problems cannot be overcome. (...) There are some technical issues that (...) (25 years ago, 6-May-99, to lugnet.robotics)
|
42 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
