Subject:
|
Re: Some comments (long)
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 6 May 1999 17:22:21 GMT
|
Viewed:
|
949 times
|
| |
|
|
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.
Mark Tarrabain <markt@lynx.bc.ca> wrote:
> 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.
There are some technical issues that complicate this, namely, the way the
ROM receives a message depends on the opcode. This is not made obvious
anywhere, but basically the last digit of the opcode indicates the length
of the message. New opcodes and modified versions of old ones have to fit
within this constraint.
Also, each opcode is required (to some extent) to consume two values. You
can relax this restriction if you like, but the cost is that you change the
current IR protocol and you complicate the opcode parser.
> 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.
As I see it, the current byte code allows for 256 subroutines with no
modifications. Maybe this is not enough, but for all practical purposes I
think it is. Not saying that you can't add another opcode, but if you find
that the opcode space becomes a constraint, you might want to make do with
a 256 subroutine limit. Also, depending on how you design things, using a
16-bit function address might have implications on function relocation,
which the current interpreter uses to keep memory packed in the presence of
additions and deletions of tasks and subroutines.
Regarding using the current 32 global variables as registers, this is a
reasonable way to think of things.
One of the premises of your suggestions seemed to be that byte code
remained completely backward compatible; hence, the suggestion that the 32
global variables (now registers) remain global, and additional registers be
added for local variables. Nothing is wrong with any of this.
One thing you seemed to miss was that the current interpreter only uses 16
of a possible 256 sources. In addition, 3 of the 16 are devoted to
CyberMaster, and could be used by the RCX if you chose to design things
that way. The result is that if you want to use additional sources for
local, global, or thread-local variables (or whatever else you might find
use for additional sources as), you can.
The one caveat is that the test and branch opcodes limit the source
specifier to four bits. However, the encoding for the opsrc parameter of
these opcodes (which currently stores the aforementioned four source bits)
appears to have two bits free. I believe these bits are normally zero.
You can thus use these to bits to allow up to 64 source types.
-Kekoa
|
|
Message has 1 Reply:
 | | Re: Some comments (long)
|
| (...) Could you explain what you mean by this, exactly? I would have figured that if a new interpreter is designed from scratch, the lengths of the opcodes could be hard-coded into the interpreter in some way. I was not suggesting that any existing (...) (25 years ago, 6-May-99, to lugnet.robotics)
|
Message is in Reply To:
42 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
