Subject:
|
Re: Some comments (long)
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 6 May 1999 17:54:07 GMT
|
Viewed:
|
900 times
|
| |
|
|
Kekoa Proudfoot wrote:
>
> 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.
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 opcodes be modified in length at all..
> 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.
Could you elaborate on this please? Thanks.
> 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.
Relocation doesn't have to be an issue with 16 bit addresses because the
addresses can be 'start of program' relative. 16 bit addresses for variable
space can also be 'start of data space' relative, so the program can slide
anywhere in memory, as long as it's all kept together. This slows the
interpreter down ever so slightly, since it will need to perform a single add
operation every time an address is referenced, but I would consider the
overhead of a simple operation such as add as negligible for all intents and
purposes.
> 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.
Thank you. :)
Actually, in fact, I was suggesting that additional registers be added for
"thread-local" variables, and that the stack be used for variables local to a
given function. The stack addressing (and the proposed 16 bit global variable
addressing) would only be used to move data to or from the registers, so
existing opcodes wouldn't have to worry about accomodating the new addressing
modes.
> 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.
Actually, I had noticed this, but did not comment on it because the set
variable instruction does not allow a specification of a source mode for the
destination, since a variable is always assumed. It just seemed more practical
to me to use registers numbered above 32 instead, giving full read-write
privileges that are still compatible with the existing opcode set.
> > Mark
|
|
Message has 1 Reply:
 | | Re: Some comments (long)
|
| (...) Assuming you use the ROM to receive things, which would be prudent in terms of space but not strictly necessary, the lengths of the opcodes in the message receiving code are determined by the lowest three bits of the opcode: 0 means length 0, (...) (25 years ago, 6-May-99, to lugnet.robotics)
|
Message is in Reply To:
| | 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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
