Subject:
|
Re: Some comments (long)
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 6 May 1999 21:00:33 GMT
|
Viewed:
|
981 times
|
| |
|
|
Mark Tarrabain <markt@lynx.bc.ca> wrote:
> 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..
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, 1 means length 1, 2-4 mean lengths 2-4, 5 means
the length is stored as part of the data, etc. This is documented in the
RXI code in the Rom section of the web pages. The IR code will fail (i.e.
dump the message) if the length is not as expected.
Maybe you don't intend to allow a subset of the opcodes to be sent from PC
to RCX, or maybe you do not intend to use the ROM to receive messages, and
much of this does not matter.
> > 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.
The IR protocol uses the 0x08 bit of the opcodes as a sequence bit to make
sure the same opcode, sent twice because the PC did not receive an
acknowledgement the first time, is not actually executed twice if the RCX
receives it two times. All opcodes sent over IR, with the exception of
0xf7 (set message), therefore take up two values in the opcode number
space, one with the 0x08 bit set, and one with it not set.
Again, if you do not care about sending certain opcodes across IR, you can
relax this restriction, with the caveat that you complicate the parser.
You can do a switch on (opcode & ~0x08), but then for the opcodes that are
doubled up, you have to look at the 0x08 bit to see which opcode was really
intended.
> Relocation doesn't have to be an issue with 16 bit addresses because the
> addresses can be 'start of program' relative.
Only if you disallow changing a subroutine or task without changing the
entire program. As things are now, everything is position independent, and
you can change a single subroutine or task and all the others remain
intact. This is a reasonable thing to lose if you are willing to lose it;
I just thought I'd point out that it breaks the current model for doing
things.
> 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.
You have to be careful when relocating data. I'm not sure what your model
of a data space is (is there one data space? how does a task's stack fit
into this? are there pointers? etc.); all I can say is make sure you think
twice about how relocation interacts with your data model if you are going
to allow relocation.
The model I proposed a day or two ago allows relocation by using an index
into one of several data areas/variable frames (function-local, task-local,
global) to allow relocation, and this is similar to what you now seem to be
proposing.
Oh, one nit: by using the word "address" I assumed you meant something that
absolute; if you had instead used the word "offset" I would have known you
were thinking of something relative.
> 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.
I think the whole notion of a register complicates things somewhat, since
you don't really need registers. Every operation in the byte code uses
source plus argument; if you use one source to access values in a global
data space, another to access values in a thread-local data space, and a
third to access a stack-like function-local data space, you don't need
registers since you can access the three data areas directly. If you want
scratch space, you can allocate data in either the task-local or
function-local data spaces for that purpose. The model I proposed two days
or so ago didn't have registers for exactly these reasons.
> > 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.
This is true. My only point was that you don't need a new set of opcodes
to access every new data area you might introduce. Just use different
sources. You might need a single new opcode that stores any single
variable in any source plus argument destination, like set variable but
with the source on the other side.
In the model I proposed, source 0 was for task-local variables, and that
was what I saw being the scratch space. I did not assume backwards
compatibility for source 0 arguments 0..31, but that wouldn't have been
hard to add.
I'm not so sure on the backwards compatibility thing. Can you rattle off a
list of reasons why that might be useful? Here's my list of pros/cons:
+ less firmware reloading for some (since new firmware works as old did)
+ less changes to NQC compiler
+ OCX still works, and so do existing tools
- limits flexibility; cannot reorganize opcode space
- OCX cannot use new features, and is thus somewhat useless
- new tools need to be written no matter what
-Kekoa
|
|
Message has 1 Reply:
 | | Re: Some comments (long)
|
| (...) At the risk of splintering the development efforts here from 2 to three, I've been wondering the same thing. I guess I'm not as concerned with ensuring that my existing OCX code works - I'd rather see any new OS make the RCX "be all that it (...) (25 years ago, 7-May-99, to lugnet.robotics)
|
Message is in Reply To:
| | 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)
|
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
|
|
|
|
