Subject:
|
Re: anyone know how to check free space on RCX?
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Fri, 12 Jul 2002 18:36:18 GMT
|
Viewed:
|
5483 times
|
| |
|
|
On Fri, 12 Jul 2002, Jason Clark wrote:
> According to config/h8300/h8300.h in the gcc sources, int is 32bit for the
> h8 cross compiler. I believe the reason mm_free_mem() returns an int is
> because the memory manager stores the size of each free block as size_t,
> which is defined in mem.h to be 'unsigned', i.e. unsigned int.
> mm_free_mem() adds these blocks' sizes up and returns the result. It is
> interesting to note that <sys/mm.h> says:
This can't be right. I'm about 99% sure that all of the ints I've used
with my legOS programs have been 2 bytes. When using LNP to send RCX ints
to a PC, for example, you have to use short on the PC end of things to
make it all work right.
> #define MM_HEADER_SIZE 2 //!< 2 words header: pid, size
>
> Indicating that the size of the block is stored in a word, and yet all the
> code in mm.c treats the headers as a pair of size_t elements (i.e unsigned
> or unsigned int). Can anyone else comment on this? I admit I'm still new
> to legOS and the kernel sources, but it seems straightforward. Why would
> the memory manager use all ints when 32bit math is so much slower on an h8?
> I feel like i'm missing something.
This is another reason why 32-bit ints make no sense; int is almost never
a size that isn't native to the processor. So either you misread the
header or... I guess I don't quite understand. Any comments on that?
> To display a 32bit value as two hex words, i would do this:
> cputw(myInt >> 8);
> sleep(1);
> cputw(myInt);
Actually you would do cputw(myLong >> 16) on the first line.
> lcd_int() is actually a #define for a call to the ROM function lcd_number(),
> which prevents me from inspecting the source code :P The comments in
> <rom/lcd.h> explain partially (it should display a signed integer, no
> decimal), but I can't tell how overflowing the size of the LCD is handled.
Given what people have said, apparently it outputs 9999 when the number is
too large.
--
"From now on, we live in a world where man has walked on the moon.
And it's not a miracle, we just decided to go." -- Jim Lovell
Mike Ash - <http://www.mikeash.com/>, <mailto:mail@mikeash.com>
|
|
Message has 1 Reply:
Message is in Reply To:
13 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
|
|
|
|
