To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcx.nqcOpen lugnet.robotics.rcx.nqc in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / NQC / 245
244  |  246
Subject: 
Re: NQC wishlist
Newsgroups: 
lugnet.robotics.rcx.nqc
Date: 
Tue, 23 Nov 1999 02:57:28 GMT
Viewed: 
1939 times
  
Dave,

All of these additions to NQC sound great ... especially the char and
bool data types!

There is no way that we (all the NQC users) can adequately express our
appreciation for all of your work in developing and freely distributing
NQC.  I hope your book sells millions of copies!

- Nick -


Dave Baum wrote:

In article <FLLC2F.EtI@lugnet.com>, "Vlad Dumitrescu"
<vladdu@nospam.hotmail.com> wrote:

I am not sure if there is such a wishlist... I remember there was a "call for
wishes" for RxCC...

The biggest problem with the standard firmware is the small amount of
variables. Since not every use of a variable will use all 16 bits, I think it
would be neat to include in the language a way to specify how many bits to be
used for a variable, and automatically handle all bit allocations and
operations. Right now it is rather tedious to use lots of macros and keep track
of which bit means what... I think many people will appreciate this.


I'm not really comfortable with variable-length bit allocations since this
isn't something that happens in C outside of structs.

But there could still be a couple "smaller" types.  Right now an int is 16
bits.  Perhaps a char could be 8 bits, and a bool (borrowed from C++) is 1
bit.  These would then get packed into as many 16 bit variables as
needed.  I like this idea - especially the notion of bool - since there
are many cases where 16 bits is overkill.  I tend to have lots of boolean
flags in my code.

Another thing to do might be introducing arrays - it's a similar handling, only
in the other direction ;-)


There is no bytecode level support for indirect addressing, therefore I
could support something like this:

int foo[2];

foo[0] = 7;
foo[1] = foo[0] + 3;

But I couldn't support this:

int foo[2];
int x;

foo[x] = 1;

Since the later is really the whole point of arrays, I'm not sure how much
value there would be in simply glomming a lot of ints together and always
needed to access them via a compile-time constant index.

Dave Baum

--
reply to: dbaum at enteract dot com



Message is in Reply To:
  Re: NQC wishlist
 
(...) I'm not really comfortable with variable-length bit allocations since this isn't something that happens in C outside of structs. But there could still be a couple "smaller" types. Right now an int is 16 bits. Perhaps a char could be 8 bits, (...) (25 years ago, 23-Nov-99, to lugnet.robotics.rcx.nqc)

17 Messages in This Thread:







Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR