|
If anyone is seriously considering this I'd ask two things...
1) Have you considered porting the p-code interpreter used by Interactive
C or something like a stripped down Java bytecode interpreter instead?
The idea here would be that the RCX bytcodes are seriously crippled, and
rather then hacking our way up the chain, why not start with something
that was designed for more power up front. Also with either solution
you'd get ready-made tools with Interactive C or a Java compiler.
2) If you want NQC to support the extensions, *please* talk to me before
starting work on them. You'd basically be adding a new 'target' for NQC
and I'd want to make sure its as consistent as possible with the three
existing targets (RCX, CyberMaster, Scout).
Dave Baum
In article <slrn874f9k.nog.mattdm@jadzia.bu.edu>, mattdm@mattdm.org wrote:
> Jacob Schultz <gandalf@superbruger.dk> wrote:
> > I was jut wondering, has anybody tried to implement a "better RCX-code"?
> > It must be possible to write something very similar to RCX-code in
> > LegOS, only faster and implementing the "missing" array structures and
> > more variables. Mayby compatible with ordenary RCX-code.
>
> Yeah, this was discussed way back at the beginning of the
> reverse-engineering effort. It's something I'd like to see too.
--
reply to: dbaum at enteract dot com
|
|
Message has 3 Replies: | | RE: NQC wishlist
|
| (...) This might be a good idea. The pbForth thing is working out well too. Maybe a C to FORTH translator would be useful. In the other hand, making a custom bytecode interpreter means having to write the interpreter and support it on different (...) (25 years ago, 4-Jan-00, to lugnet.robotics.rcx, lugnet.robotics.rcx.nqc)
|
Message is in Reply To:
9 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
|
|
|
|