Subject:
|
Re: Something else is needed, I think...
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Mon, 3 May 1999 22:15:49 GMT
|
Original-From:
|
John A. Tamplin <jat@liveonthenet%spamcake%.com>
|
Viewed:
|
1278 times
|
| |
|
|
On Mon, 3 May 1999, Mark Tarrabain wrote:
> Just a couple of comments on what I think a new byte code should do or be
>
> 1) It should resemble machine language. The commands in the bytecode
> should be low-level enough to not be representative of any high-level language
> in particular. Further, the bytecode set should be sufficient to be able to
> implement any general algorithm (i.e. not rcx-specific) about as easily as it
> would be implemented in a machine language.
Basically what you are talking about at this level is an interpreted
machine language. The only benefit you get from interpreting it rather
than running directly on the hardware is that you can catch errors. However,
if the bytecodes are roughly at the same level as machine code, you will find
that the errors you want to catch have been obscured by this point (ie, you
want to make sure you don't go off the end of an array, indirect through an
uninitialized pointer, etc).
> 2) There should be no facet of rcx-specific behaviour that cannot be done
> through some sequence of these bytecodes. The rcx-specific opcodes should be
> kept to the barest minimum but still be sufficient enough that it does not
> restrict what can be done with the rcx hardware wit a reasonable number of
> instructions.
Would you intend this bytecode to have interrupt handlers? If not, you will
have to do at least some busy waiting. If you do, then you are leaving a lot
of the complexity visible which you are trying to hide. Another issue is
language & OS issues for multithreading.
> 3) The bytecode interpreter could contain floating point emulation (This
> one's not so important in my opinion because it may prove to be more difficult
> than it's worth) .
That's trivial. Assuming your new interpreter is written using GCC, you
get that for free already. Even if it isn't, call the FP emulation
libraries yourself when you see a FP bytecode.
John A. Tamplin Traveller Information Services
jat@LiveOnTheNet.COM 2104 West Ferry Way
256/705-7007 - FAX 256/705-7100 Huntsville, AL 35801
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
Message has 2 Replies:
 | | Re: Something else is needed, I think...
|
| (...) Yes. (...) Wrong. Because we could design the instruction set from scratch ourselves, a small set of instructions could be included in the entire instruction set which do things require a great deal of regular machine instructions to do. (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Something else is needed, I think...
|
| (...) Thank you. Kekoa. I was starting to think I was completely alone in my attitudes. Just a couple of comments on what I think a new byte code should do or be 1) It should resemble machine language. The commands in the bytecode should be (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
67 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
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
