Subject:
|
Re: anyone know how to check free space on RCX?
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Fri, 12 Jul 2002 15:54:11 GMT
|
Viewed:
|
2339 times
|
| |
|
|
In lugnet.robotics.rcx.legos, Joseph Woolley writes:
> That is very interesting Jason. It is interesting that mm_free_mem()
> returns a 16bit value using a 32bit return code. Both int and long are
> 32bit value on most computers/compilers these days; short would be a 16bit
> value; and char would be an 8bit value. Maybe mm_free_mem() should return
> an unsigned short instead.
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:
#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.
> I have used lcd_int and cputw to display 32bit values (although I am not
> sure if lcd_int displays the value in hex or dec. I may be wrong about it
> displaying hex). So lcd_int is looking only at the first word, whereas
> cputw is looking at the second word.
cputw() accepts an 'unsigned', and displays the final 4 hex digits:
for(i = 1; i < 4; i++) {
cputc_hex(word & 0x0f, i);
word >>=4;
}
To display a 32bit value as two hex words, i would do this:
cputw(myInt >> 8);
sleep(1);
cputw(myInt);
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.
And since I'm away from home visiting family, I am RCX-free this weekend
(yuck), so I can't conduct any tests just now. I will probably write some
code next week to put these call through their paces, as well as check on
some data type sizes.
-Jason
|
|
Message has 2 Replies:
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
|
|
|
|
