OSDev.org

The Place to Start for Operating System Developers
It is currently Wed Apr 24, 2024 12:23 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Coding style: uint8_t for 256 entries
PostPosted: Fri Nov 27, 2015 1:59 pm 
Offline
Member
Member

Joined: Sat Mar 01, 2014 2:59 pm
Posts: 1146
Hi,

This is not so much a question of how to write code, but a matter of coding style. Say I have some code like the following:
Code:
#define TABLE_ADDRESS (void*) 0x00030000
#define TABLE_SIZE 256

static void init_table()
{
   domain   (*table)[TABLE_SIZE];
   uint8_t   current_entry;

   table = TABLE_ADDRESS;

   current_entry = 0;
   while (current_entry < TABLE_SIZE)
   {
      ((*table)[current_entry]).name = NULL;
      ((*table)[current_entry]).format = 0;
      ((*table)[current_entry]).size = 0;

      current_entry += 1;
   }
}
The relevant lines here are "#define TABLE_SIZE 256", "uint8_t current_entry;", and "while (current_entry < TABLE_SIZE)". As you can see, the loop will never end because current_entry will keep wrapping round from 0 to 255 and never reach 256.

So how should I make it so that I can count 256 values in a uint8_t? Using a uint16_t seems a bit wasteful here, but in reality I have to limit the table size to only 255 values. It really seems like I should be able to initialise an array of 256 values using a uint8_t for the counter, but I may be wrong. Am I missing something here, or do I really need to either reduce the table to 255 values or switch to a uint16_t for the counter? If so, which of the latter two would be more acceptable (considering that the size of the table is kind of flexible)?

Thanks,

onlyonemac

_________________
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.

Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing


Top
 Profile  
 
 Post subject: Re: Coding style: uint8_t for 256 entries
PostPosted: Fri Nov 27, 2015 2:04 pm 
Offline
User avatar

Joined: Sat Nov 14, 2015 3:59 am
Posts: 4
Location: Netherlands
If you insist on using uint8_t, how about
Code:
   uint8_t current_entry = 0;
   do
   {
      ...

      current_entry += 1;
   } while (current_entry > 0);

?

_________________
Code:
repne cmpsb


Top
 Profile  
 
 Post subject: Re: Coding style: uint8_t for 256 entries
PostPosted: Fri Nov 27, 2015 3:24 pm 
Offline
Member
Member

Joined: Thu Mar 25, 2010 11:26 pm
Posts: 1801
Location: Melbourne, Australia
onlyonemac wrote:
Using a uint16_t seems a bit wasteful here,
You should use an int or a size_t and allow the compiler to decide the best way. There isn't any waste since current_entry is a stack variable and will be aligned as the compiler sees fit anyway.

_________________
If a trainstation is where trains stop, what is a workstation ?


Top
 Profile  
 
 Post subject: Re: Coding style: uint8_t for 256 entries
PostPosted: Fri Nov 27, 2015 3:25 pm 
Offline
Member
Member
User avatar

Joined: Wed Dec 01, 2010 3:41 am
Posts: 1761
Location: Hong Kong
onlyonemac wrote:
So how should I make it so that I can count 256 values in a uint8_t? Using a uint16_t seems a bit wasteful here


No. The array index will likely to be promoted to native address size anyway.
I suggest to use native integer or size_t to give you flexibility to change the table size.


Top
 Profile  
 
 Post subject: Re: Coding style: uint8_t for 256 entries
PostPosted: Fri Nov 27, 2015 3:40 pm 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4594
Location: Chichester, UK
Am I missing something here?

Why not use a "for" loop? (It may be no more efficient, but it is a clearer style of coding IMO.)

Edit: I should add, use a uint_16. If your C-compiler is at all recent you can declare the variable within the loop ( "for (uint_16 i = ... )" ) so it will only use the extra byte of storage whilst the loop is executing. Hardly a big deal. In any case the lifetime of the variable is likely to be fairly short so you are worrying about nothing when you say it is wasteful.


Last edited by iansjack on Fri Nov 27, 2015 3:58 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Coding style: uint8_t for 256 entries
PostPosted: Fri Nov 27, 2015 3:46 pm 
Offline
Member
Member

Joined: Sat Mar 01, 2014 2:59 pm
Posts: 1146
cmpsb wrote:
If you insist on using uint8_t, how about
Code:
   uint8_t current_entry = 0;
   do
   {
      ...

      current_entry += 1;
   } while (current_entry > 0);

?
Sounds interesting, if not a little hackish, although I'm not familiar with using do ... while loops in C so I am more likely to get "off-by-one" bugs if I use them in the few places where I need to iterate through this table.
bluemoon wrote:
onlyonemac wrote:
So how should I make it so that I can count 256 values in a uint8_t? Using a uint16_t seems a bit wasteful here


No. The array index will likely to be promoted to native address size anyway.
I suggest to use native integer or size_t to give you flexibility to change the table size.
That seems like a good idea; I might do that, although the thing is that if I switch to a 32-bit index then I feel compelled to "max out" the array size and have 4294967296 entries lol. Such are the joys of Asperger's...

Anyway, I might just leave it at 255 for now. This table is really only used in one code module, and the size of the table doesn't honestly affect anything except the maximum number of items that can be handled by that module. 256 is more than enough; extending it at any time would require modification of that module only because of the abstraction between it and other modules.

_________________
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.

Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing


Top
 Profile  
 
 Post subject: Re: Coding style: uint8_t for 256 entries
PostPosted: Fri Nov 27, 2015 3:50 pm 
Offline
Member
Member

Joined: Mon Feb 02, 2015 7:11 pm
Posts: 898
Use an int or a size_t. I prefer the former, some prefer the later.

_________________
https://github.com/kiznit/rainbow-os


Top
 Profile  
 
 Post subject: Re: Coding style: uint8_t for 256 entries
PostPosted: Fri Nov 27, 2015 3:50 pm 
Offline
Member
Member

Joined: Sat Mar 01, 2014 2:59 pm
Posts: 1146
iansjack wrote:
Why not use a "for" loop? (It may be no more efficient, but it is a clearer style of coding IMO.)
That would not change anything, as the loop condition is still evaluated before execution of the loop body. The only solution that I can see that works with a uint8_t is the one suggested by cmpsb.

_________________
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.

Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing


Top
 Profile  
 
 Post subject: Re: Coding style: uint8_t for 256 entries
PostPosted: Fri Nov 27, 2015 3:53 pm 
Offline
Member
Member

Joined: Mon Feb 02, 2015 7:11 pm
Posts: 898
Relying on the uint8_t's overflowing to 0 is non-standard / non-conforming / non-portable and will get you in trouble at some point.

Basically, underflow/overflow behaviour for integers is undefined in the C and C++ standards. The compiler can and will optimize this into an infinite loop depending on the compiler options you use.

Just use an a signed int, it's the safest thing and the most efficient as well.

_________________
https://github.com/kiznit/rainbow-os


Top
 Profile  
 
 Post subject: Re: Coding style: uint8_t for 256 entries
PostPosted: Fri Nov 27, 2015 4:00 pm 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4594
Location: Chichester, UK
onlyonemac wrote:
iansjack wrote:
Why not use a "for" loop? (It may be no more efficient, but it is a clearer style of coding IMO.)
That would not change anything, as the loop condition is still evaluated before execution of the loop body. The only solution that I can see that works with a uint8_t is the one suggested by cmpsb.

Yes; I clarified my post in an edit. I just think that a "for" loop is cleaner when iterating a fixed number of times.

But, in any case, as I mention in my edit, the worry about larger variables being wasteful is illusory. They are only transitory.


Top
 Profile  
 
 Post subject: Re: Coding style: uint8_t for 256 entries
PostPosted: Fri Nov 27, 2015 4:10 pm 
Offline
Member
Member

Joined: Sat Mar 01, 2014 2:59 pm
Posts: 1146
Yes I get it that having a larger variable is not really wasteful of space or processing power, but it still feels "wasteful" to have a whole extra 8 (or 12) bits when only one of those bits is used on and only on the very last iteration of the loop. Using a uint8_t seems "cleaner" when I am only needing a relatively small number of items, so I will just make it 255 elements instead of 256 as it doesn't *really* make a difference.

_________________
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.

Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing


Top
 Profile  
 
 Post subject: Re: Coding style: uint8_t for 256 entries
PostPosted: Fri Nov 27, 2015 4:40 pm 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4594
Location: Chichester, UK
If you only need 255 elements then a uint_8 is fine. But don't make the mistake of confusing what seems to be wasteful with what actually is. You can waste a lifetime chasing illusory "improvements" to code. Using one extra byte for a few moments is not wasteful (especially when you are initializing a 256 element array of structures each consisting of several bytes).


Top
 Profile  
 
 Post subject: Re: Coding style: uint8_t for 256 entries
PostPosted: Fri Nov 27, 2015 10:41 pm 
Offline
Member
Member

Joined: Wed Sep 07, 2011 3:34 pm
Posts: 112
If you are interested in that level of constraint of resources (whether for fun, for OCD, or for some other reason), you probably want to use assembly anyway. Tell GCC to dump the assembly code for your program and look at it - you'll probably see more "unnecessary" uses of wide registers/aligned memory than your loop variable.


Top
 Profile  
 
 Post subject: Re: Coding style: uint8_t for 256 entries
PostPosted: Sat Nov 28, 2015 12:41 am 
Offline
Member
Member

Joined: Tue Jan 20, 2015 8:33 pm
Posts: 29
onlyonemac wrote:
Yes I get it that having a larger variable is not really wasteful of space or processing power, but it still feels "wasteful" to have a whole extra 8 (or 12) bits when only one of those bits is used on and only on the very last iteration of the loop. Using a uint8_t seems "cleaner" when I am only needing a relatively small number of items, so I will just make it 255 elements instead of 256 as it doesn't *really* make a difference.

If 'waste' is what you're concerned with, consider that the compiler will almost definitely be using a full word (32 or 64 bits) for that variable - it's likely to just be in a register, but even in memory, the compiler is pretty likely to make sure it's word-aligned by padding it with extra bytes. The only one being wasteful is you, by not using those bits to free yourself from trivial worries like this :D


Top
 Profile  
 
 Post subject: Re: Coding style: uint8_t for 256 entries
PostPosted: Sat Nov 28, 2015 3:11 am 
Offline
Member
Member

Joined: Fri Jan 30, 2015 4:57 pm
Posts: 215
Location: Germany
kiznit wrote:
Basically, underflow/overflow behaviour for integers is undefined in the C and C++ standards.

Over/Underflow for unsigned integers is well defined :) :
Quote:
A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 60 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group