Subject:
|
Some more comments and suggestions.
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 6 May 1999 17:05:15 GMT
|
Viewed:
|
1020 times
|
| |
|
|
Wes Matchett wrote:
> My request to both groups is: don't go 'off-list' until you have a feature spec
> that was formed with feedback from the whole list. It would be a shame for you
> to finish development of a tool that no one else uses.
I concur with this opinion. I realize that the subject may be a bit prevalent
right now but the alternative would be to develop a separate list for alternative
firmware discussion, and I don't know how viable that would be.
What follows is a tentative list of new ideas to incorporate into a new bytecode
interpreter that is compatible with the current one:
The original 32 variables become global registers.
Registers numbered 32 to 47 are local to threads. Each thread has its own copy
of these 16 registers. One of these registers is reserved for use as a stack
pointer (I recommend register 32, but it doesn't really matter. Maybe even
allocate one more register for the purpose, numbered 255). I am flexible on the
exact number of thread-local registers, but I do maintain that the count should not
be too high. The amount of space allocated for stack for each thread should also
be kept down (due to the limited RAM on the RCX).
These instructions can be used to manipulate the stack:
push reg
pop reg
To allocate stack space for local variables or to free up stack space used by
parameters and local variables, the existing add and subtract instructions could be
used, specifying as its destination the new register which is designated as stack
pointer.
For data movement to and from registers, I would recommend instructions like the
following:
mov reg,address
mov address,reg
mov reg,address+reg
mov address+reg,reg
mov reg,[reg]
mov [reg],reg
mov reg,[reg]+reg
mov [reg]+reg,reg
And, if you will forgive the intel-ish syntax, similar instructions for accessing
data inside the stack:
mov reg,stack:address
mov stack:address,reg
mov reg,stack:address+reg
mov stack:address+reg,reg
mov reg,stack:[reg]
mov stack:[reg],reg
mov reg,stack:[reg]+reg
mov stack:[reg]+reg,reg
For those of you who may be unfamiliar with concepts of assembly, the notation
[reg] is an indirect addressing mode, where 'reg' contains an address.
For calling subroutines:
call address
call [reg]
The second form permits a robust indirect function call.
On account of the increased size of the interpreter that may result from this
enhanced implementation, it may not be viable to still permit 5 separate programs
to simultaneously be loaded into the RCX. Presently, I don't know how important
this issue might be.
The proposed 20 instructions mentioned above consume just about 1/3 of the total
available opcodes left by the existing interpreter.
These are my first thoughts on the issue. Any comments?
> > Mark
|
|
Message has 2 Replies:
 | | Re: Some more comments and suggestions.
|
| (...) That's a good pseudo-question. It would actually be quite easy to set up a focused group/list for this, as has been done for legOS, NQC, and pbFORTH; the viability is only dependent on the interest in having more room to breathe. Anything (...) (25 years ago, 6-May-99, to lugnet.robotics)
| | | Request for new list
|
| I request that the discussions of alternate firmware implementation details go into their own newsgroup now. Discussions about features can be crossposted to both lists. There were several requests recently to create a new group for newbies to (...) (25 years ago, 7-May-99, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Some comments (long)
|
| (...) My request to both groups is: don't go 'off-list' until you have a feature spec that was formed with feedback from the whole list. It would be a shame for you to finish development of a tool that no one else uses. -Wes (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
|
|
|
|
