Subject:
|
Re: Something else is needed, I think...
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Mon, 3 May 1999 23:04:05 GMT
|
Original-From:
|
John A. Tamplin <jat@liveonthenet!avoidspam!.com>
|
Viewed:
|
1375 times
|
| |
|
|
On Mon, 3 May 1999, Mark Tarrabain wrote:
> > 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.
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.
> > 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)?
Actually, you need to have a call stack and a value stack in order to keep
from crashing in the face of some bytecode errors. Aside from not having
the display stack to support Pascal, you now have UCSD pCode. Depending on
how pbForth is implemented (I haven't looked at it but I wrote a forth
threader many years ago), you may be able to use its threader as your
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.
egcs-1.1.2 (and others) has FP emulation built into libgcc.a as long as you
properly build it as a cross compiler. libgcc.a has the helper routines
required for integer multiply and divide already, so if you do anything
serious on it you either manually link it in or use the crt0 I posted several
months ago (or something similar) and use gcc to link rather than ld.
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 1 Reply:
 | | Re: Something else is needed, I think...
|
| (...) Sorry to step in here. But there is no difference (as I see it) between having a system library function that runs the motors and having a byte code that runs the motors. It's all a matter of encoding. If I say: set_motor_speed(MOTOR1, 20); (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
Message is in Reply To:
| | 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)
|
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
|
|
|
|
|
|
