Page 1 of 2
Porting your OS
Posted: Thu Aug 21, 2008 11:15 pm
by salil_bhagurkar
Hey all!!
I have read in various tutorials that you need to define stuff like u8,u16,u32... for portability. But I have been using int, char and long these days in my os. So I wanted to understand the exact need behind doing this. I do understand that if you port your os between architectures (like 32bit -> 8 bit) then this is an advantage, as the size of the variables you use in memory mapped structures (like file system super blocks etc) remains same.
But what about the usual code, where you simply need a counter? Like for example you need to find the factorial of a number, then you can use int instead of u32. In addition, i guess it is safe to use char in case of strings since the size of a character in a string always remains same in case of all architectures...
Re: Porting your OS
Posted: Fri Aug 22, 2008 6:08 am
by JamesM
Hi,
Those defines aren't just for ensuring that type sizes are the same across platforms - types like size_t and uintptr_t are deliberately sized to give optimal performance for each system. It's always more efficient to perform arithmetic on integer sizes that are the same as the general purpose register size.
Cheers,
James
Re: Porting your OS
Posted: Fri Aug 22, 2008 6:35 am
by Solar
In theory the width of an int could change between
compiler versions...
Of course there are places where a simple "int" does the trick - if you need a loop counter for 50 runs of a loop, it'd be overkill to use any special defines.
The rest is a mixture of "better safe than sorry" and simple outright pedantery (the type of an array index is size_t, says the standard...).
Re: Porting your OS
Posted: Fri Aug 22, 2008 11:04 am
by salil_bhagurkar
So I guess you have to be a little alert when writing code like loops. Since if you use an int in some code that creates for example 300 devices in the memory, then it would probably work on 32 and 16 bit architectures. But this code will screw up on an 8 bit architecture. In this case, hence, the defines would be probably more useful. But at the same time, one point of view would say that, on 8 bit architectures, the os would be probably stripped so much, that you won't have to create as many as 300 devices. That solves the problem unknowingly...
Following this assumption, I am using ints everywhere for normal code. Wherever the code requires you to have a specific bit width, there I use the u32,u16... And yes I have used the 'size_t' wherever it should be used...
One thing i have wondered though, is why does the linux source have 'unsigned longs' instead of unsigned ints...? Both are same on 32 bit architectures and as far as i know linux has not still gone to lower bus width architectures. I guess it should be because in case of 64 bit code, unsigned long still remains 32 bits. But still what is the need to have smaller variables, when an unsigned long long (which would be the unsigned int in case of 64 bit) would prove to be faster for the CPU...?
Re: Porting your OS
Posted: Fri Aug 22, 2008 12:04 pm
by JamesM
I guess it should be because in case of 64 bit code, unsigned long still remains 32 bits.
Not quite the case.
32-bit, given current release of GCC 4.3:
char: 1 byte
short: 2 bytes
int: 4 bytes
long: 4 bytes
long long: 8 bytes.
64-bit, given same assumption:
char: 1 byte
short: 2 bytes
int: 4 bytes
long: 8 bytes
long long: 8 bytes.
So there you go. It's unsafe code.
Re: Porting your OS
Posted: Fri Aug 22, 2008 12:18 pm
by bewing
Which is why, occasionally, you will see people on these boards talking about creating a new programming language where all the standard type sizes are fixed by definition. It is also a reason for people to code OSes in ASM. It is too much of a pain in the behind to keep track of "what happens to my code if type X is not Y bytes"? OS structures must be precisely defined, for the API -- and not compiler dependent.
Re: Porting your OSan unsigned int will provide optimal performa
Posted: Fri Aug 22, 2008 2:31 pm
by Alboin
Following this assumption, I am using ints everywhere for normal code.
IIRC, the linux rule is to use unsigned int everywhere (Granted you don't need signedness.) because it provides the best performance on the most architectures.
Re: Porting your OS
Posted: Fri Aug 22, 2008 9:05 pm
by Brynet-Inc
Personally, I think the custom "u32/u16" or... u32int (JamesM
) are annoying, please if you do, use
stdint.h types instead.
Re: Porting your OS
Posted: Sat Aug 23, 2008 11:47 am
by salil_bhagurkar
bewing wrote:Which is why, occasionally, you will see people on these boards talking about creating a new programming language where all the standard type sizes are fixed by definition. It is also a reason for people to code OSes in ASM. It is too much of a pain in the behind to keep track of "what happens to my code if type X is not Y bytes"? OS structures must be precisely defined, for the API -- and not compiler dependent.
That is not the only reason why even i am designing my own virtual machine inside my os. There are lots of things you have to take care when you are writing code for architectures. It's never possible to write code that is completely abstracted and generalized. You always end up writing code that is specific for the architecture or set of architectures. This is in fact unavoidable since the work that you do on these architectures is so much governed by the hardware that these architectures provide...
Re: Porting your OS
Posted: Tue Aug 26, 2008 3:49 am
by AndrewAPrice
I only really see the use of using uint32, f32, etc is if you're working with a device driver and want to support multiple architectures.
Re: Porting your OS
Posted: Tue Aug 26, 2008 10:01 am
by Dex
I ported my ASM code OS from x86 to ARM by just rewriting it, this may seem like alot of work, but it was really easy, about the same work as say writng a tcp/ip stack.
At the same time as porting, i was also learning to code in ARM ASM, but it was also easy.
So remember the first time you write a OS is much harder than the next time, same with learning to code.
I see so many OS rewrites, why not get it right the first time and use the rewrite time to port.
Re: Porting your OS
Posted: Tue Aug 26, 2008 10:22 am
by quok
MessiahAndrw wrote:I only really see the use of using uint32, f32, etc is if you're working with a device driver and want to support multiple architectures.
And why wouldn't you want to support multiple architectures? Sure, it might not be a goal right now, but it might be in the future, and using these types would make your job a lot easier down the road. Plan for the future, I always say.
Re: Porting your OS
Posted: Tue Aug 26, 2008 11:05 am
by salil_bhagurkar
As for me, i only use the processing part of the underlying processor. I recently did a rewrite of my os (which removed all the x86 specific crap). My os now only depends on the processing part, the interrupts and other few things which are available on all architectures. I have not used any x86 specific stuff like paging and all. I will be having the equivalents of all the facilities that a modern processor gives you in my virtual machine that runs on top of my os. Right now i am not thinking of speed..
...So i have put all the minimal architecture specific code in a folder arch (like everyone, but theres too less code in it). It seems that it will be pretty easy for me to port the os to any architecture in the future.
Re: Porting your OS
Posted: Sat Aug 30, 2008 1:39 pm
by JamesM
Brynet-Inc wrote:Personally, I think the custom "u32/u16" or... u32int (JamesM
) are annoying, please if you do, use
stdint.h types instead.
Aye, the rewrite of my tutorials changes all those to the standard types. I originally used u32int etc as they are used by my (ex) workplace.
Re: Porting your OS
Posted: Sun Aug 31, 2008 11:26 am
by salil_bhagurkar
@JamesM: Although theres no need, since you are getting a wonderful response for your amazing tutorial on osdev... I must say its absolutely wonderful... I was so excited about it, that i followed the tutorial and wrote one more tiny kernel from that.. (i dint follow the whole one.. just till the pit, timers..). It was a great experience...