Subject:
|
Re: FW: Something else is needed, I think...
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 5 May 1999 00:12:05 GMT
|
Original-From:
|
Ray Kelm <RHK@NEWIMAGEihatespam.COM>
|
Viewed:
|
848 times
|
| |
|
|
Kekoa Proudfoot wrote:
>
> Laurentino Martins <lmartins@marktest.pt> wrote:
> > - Floating point is not optional. You may reduce the precision to a few
> > bits, or do a few hacks instead of a full blown floating point support,
> > but we definitely need some sort of floating point. If you want a bot
> > that keeps track of it's position, you need it (you also need at least a
> > sin() function/lookup table). Just one example.
>
> My take on this is that you can use fixed point if you really need extra
> decimal places. That is, work in fractions, not whole numbers.
>
> Providing sin() is difficult because of the tradeoff between memory usage
> and usability. My thoughts are that the cost of memory usage outweighs the
> benefit of having the functions available for the few (?) that will use
> them.
sin() can be simulated to enough accuracy using a small table of
floating
point constants, and some math. Fairly fast, and very small.
> > - I think most of us don't give much importance to preemptive
> > multitasking, exceptions and all the "sophisticated" programming like
> > that. Most our programs are so small that 90%+ of us will never need
> > them.
>
> Don't forget that the current firmware has multiple concurrent tasks which
> are (effectively) preempted every instruction. This at least is very
> useful, and I see it remaining useful.
multiple concurrent tasks can also be simulated within your own program.
>
> My current thoughts are that, with exception of minor details (like better
> debugging support), the primary addition made by a first crack at new
> firmware (under the assumption that it is based in principle on the current
> firmware) is going to be adding better support for variables. This will
> also be the largest addition and the biggest change to the machine model
> implemented by the current firmware. So if anybody has ideas on what
> they'd like to see in this regard, I'd like to hear them. My current ideas
> encompass support for the following:
>
> - function-local variables, with provisions for recursion
> - task-local variables
> - global variables
> - mechanisms for passing variables between caller and callee
> - possibly but doubtfully: variable references
These are all not necessary. Remember, these features exist to allow
LARGE programs to be written easily. The RCX is not going to run large
programs, no matter what you do. It'd be better to implement only
global variables and concentrate on a fast interpreter.
> - no dynamic memory allocation
Here I disagree also. dynamic allocation allows programmers to ignore a
lot
of messy details, like buffer sizes and so on.
>
> Variables of different types (function-local, task-local, global, maybe
> also function-parameter) are accessed using new source + argument
> combinations. One or more new opcodes are introduced to support the
> allocation of the various types of variable spaces. The other opcodes
> remain mostly the same.
>
> There are certainly other ways to provide better variable support; if you
> know of any, let me know.
>
> -Kekoa
I keep thinking back to my old Commodore VIC-20. It had 16k of ROM,
which
included about 10K for the basic interpreter, and 6k for the kernel
code.
It had 5K of RAM, of which only 3.5K was available for basic programs.
It ran a 1 Mhz 6502.
The RCX beats it on processor and RAM, but not on I/O. (The VIC had
two 6522 VIA's, which could do a lot). And yet, somehow, this small
machine had a complete basic interpreter, with dymamic string
allocation,
floating point (emulated, obviously), and a whole lot more.
With the very limited amount of I/O the RCX has available, there is no
real need to make a big object oriented system with local variables and
recursion. All of those things can be easily simulated using simpler
constructs.
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
Message has 2 Replies:
 | | Re: FW: Something else is needed, I think...
|
| (...) Part of my point, which I did not state clearly, was that any reasonable sin() required floating-point, and that this made sin() not worth it. But I back down from this now, for two reasons. First, you do not need floating point to implement (...) (25 years ago, 5-May-99, to lugnet.robotics)
| | | Re: FW: Something else is needed, I think...
|
| (...) Hmmm... porting Commodore Basic to the RCX... nahhh. ;-) -SMQ Shawn Menninga smq@dwarfrune.com --=--=--=--=--=--=--...-=--=--=-- "Well I've wrestled with reality for thirty-five years now, doctor, and I'm happy to state I've finally won out (...) (25 years ago, 5-May-99, to lugnet.robotics)
|
Message is in Reply To:
| | Re: FW: Something else is needed, I think...
|
| (...) Do you mean, when a timer reaches a certain value, run a specified task? Can't you do this already, or is something broken with the current firmware in this regard? (It seem that some combination of wait and start_task should do the trick, (...) (25 years ago, 4-May-99, to lugnet.robotics)
|
32 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
|
|
|
|
