Subject:
|
Re: Something else is needed, I think...
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Mon, 3 May 1999 22:35:03 GMT
|
Viewed:
|
1262 times
|
| |
|
|
"John A. Tamplin" wrote:
> Basically what you are talking about at this level is an interpreted
> machine language.
Yes.
> The only benefit you get from interpreting it rather
> than running directly on the hardware is that you can catch errors.
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. Examples of such
instructions would be anything that does something hardware specific.
> 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).
Well, they would be *SLIGHTLY* higher level, but not by much. What about making the
bytecode set represent a virtual stack machine (that is, each thread has only 2
registers - a program counter and stack pointer)?
> 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.
That should probably be handled by the bytecode interpreter.
> [FP emulation is] 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.
I wouldn't have anticipated that floating point emulation on an H8 would be easy,
but if it is, I'll take your word for it.
> > Mark
|
|
Message has 1 Reply:
 | | Re: Something else is needed, I think...
|
| (...) Well, having a bytecode for turning on a motor seems little benefit compared to calling a library function to do it. From the user's point of view, the effort and the result are similar. (...) Actually, you need to have a call stack and a (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Something else is needed, I think...
|
| (...) 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 (...) (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
|
|
|
|
|
|
