Subject:
|
Re: FW: Something else is needed, I think...
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 4 May 1999 20:43:18 GMT
|
Viewed:
|
870 times
|
| |
|
|
Kekoa Proudfoot wrote:
> 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.
I believe that a new bytecode instruction set should provide native support for
non-integer numbers of some type. Whether this is implemented as ieee single
precision numbers or as 32-bit fixed-point numbers is an issue that may be up
for some discussion. Although I personally prefer the idea of using ieee
single precision numbers (barring that such code does not require an enourmous
amount of space), I don't want to get into an argument with anyone who might
disagree. I consider myself flexible on the issue and would not object to
rationales for other approaches.
> 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.
Well, I would hope that things like sin() could be provided in a math library
that can become part of the byte-code executable. This sort of thing would
necessitate that the bytecode set be complex enough to be able to perform the
instructions necessary to accomplish the task.
> Regarding what high-level language is supported, C is also a given in my
> mind, but really it is up to the compiler writer(s) what high-level
> languages are supported, under the assumption that they can be compiled to
> byte code similar to that in the original firmware in the first place.
If the bytecode is designed reasonably well, it should not be indicative of any
particular high-level language and thus, any high-level language could be used
as a basis to build a byte-code generator. What they would all have in common,
of course, are general make-up of the RCX API calls.
> Regarding interfacing to peripherals (you gave the example of accessing a
> rotation sensor), my thoughts are to leverage the routines in ROM,
> providing a similar interface to what exists in the current byte code
> already.
Agreed.
> > - A IDE like the RcxCC and an on-line Help IS A MUST. :-)
>
> If, when the time comes, somebody is willing to write this, I'm all for it.
> As I see it, support for this sort of environment will be built into the
> firmware.
Uhm... does the firmware need to really be aware of that? All the bytecode
interpreter should have any interest in doing is executing the instructions
that it's given and respectably aborting a task when it does something
incongruent.
> 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
> - no dynamic memory allocation
I am in complete agreement with you on all of these except the last one. The
second last one, by the way, is a higher-level language issue and shouldn't
really be a part of the bytecode interpreter. Variable references should be
resolved by the compiler and the appropriate bytecode generated. With regards
to dynamic memory allocation, like the floating point issue I mentioned above,
I could probably be talked out of wanting it if I heard a good enough
rationale. For those of you who think that the issue of garbage collection
would be a concerrn, consider that garbage collection becomes either
superfluous or an NP hard problem in the case where explicit function calls are
provided for dynamic memory allocation and deallocation (as in the case of C
via malloc and free). Where dynamic memory allocation happens behind the
scenes, garbage collection becomes quite practical and implementable. Thus, if
explicit memory (de)allocation were allowed, I would *NOT* support the idea of
having automatic garbage collection. (Please direct followups on this
particular subject to me via email please.. this subject digresses considerably
from the issue of building a new bytecode interpreter for the RCX and is more
in the domain of computer science proper.)
> 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.
Yup yup yup.
> > Mark
|
|
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
|
|
|
|
