-
Android_x7
- Posts: 5
- Joined: Wed Dec 28, 2011 11:50 pm
Re: OS (What bit version is it?)
just wondering what the Operating System bit range is... is it a 16 or 32 bit as 64 bit would take to much ram up and as pi is very limited i was curiouse what bit the OS was.
-
Benedict White
- Posts: 224
- Joined: Sat Dec 24, 2011 12:24 am
Re: OS (What bit version is it?)
I believe the Arm is as it always has been 32 bit and as such so will the operating system.
-
Android_x7
- Posts: 5
- Joined: Wed Dec 28, 2011 11:50 pm
Re: OS (What bit version is it?)
good point but i was thinking with its very limited amount of ram 32 maybe to resourceful and 16 would be better for ram consumption.
but i suppose your right it would be not worth putting 16 bit on as the OS would run slowly.
but i suppose your right it would be not worth putting 16 bit on as the OS would run slowly.
-
Benedict White
- Posts: 224
- Joined: Sat Dec 24, 2011 12:24 am
Re: OS (What bit version is it?)
I can't see the point of using 16 bit, as it would waste resource. An Arm target would normally be 32 bit.
-
Android_x7
- Posts: 5
- Joined: Wed Dec 28, 2011 11:50 pm
Re: OS (What bit version is it?)
you may have misinterpreted what i have said. or you may have not. 16-bit would use less ram and 32-bit would use more ram.
-
Benedict White
- Posts: 224
- Joined: Sat Dec 24, 2011 12:24 am
Re: OS (What bit version is it?)
Android_x7 said:
you may have misinterpreted what i have said. or you may have not. 16-bit would use less ram and 32-bit would use more ram.
In what way? I have not noticed an increase in RAM usage between 32 and 64 bit intel based OS's, though the reason for compiling at 64 bit was to make more available, the RAM usage per process seemed comparable from memory but I was not measuring particularly.
The fact that 32 or 16 bits at a time can be processed does not mean they are, nor does that change the size of a byte.
you may have misinterpreted what i have said. or you may have not. 16-bit would use less ram and 32-bit would use more ram.
In what way? I have not noticed an increase in RAM usage between 32 and 64 bit intel based OS's, though the reason for compiling at 64 bit was to make more available, the RAM usage per process seemed comparable from memory but I was not measuring particularly.
The fact that 32 or 16 bits at a time can be processed does not mean they are, nor does that change the size of a byte.
Re: OS (What bit version is it?)
Benedict White said:
Android_x7 said:
you may have misinterpreted what i have said. or you may have not. 16-bit would use less ram and 32-bit would use more ram.
In what way? I have not noticed an increase in RAM usage between 32 and 64 bit intel based OS's, though the reason for compiling at 64 bit was to make more available, the RAM usage per process seemed comparable from memory but I was not measuring particularly.
The fact that 32 or 16 bits at a time can be processed does not mean they are, nor does that change the size of a byte.
I did when I went from XP 32 bit to XP 64 bit years agao my ram useage on the same system went up 5%. But I had more ram than the OS could use so I had no choice. I don't use that OS anymore but at the time it did eat up more ram, and programs compiled for 64 bit had a larger executable file. A 64 bit OS has larger address space to work with so naturally that table alone will consume more ram. Any pointer should become larger because it now contains a 64 bit address instead of a 32 bit address. The variables themselvs don't change the programmer explicitly (well not in all languages) states what size variable he/she wants like long, or double, long long, double double, byte, int, ect.
Only recently did ARM demonstrate a working 64 bit chip, so you can exclude that. A 16 bit OS (Although most 16-bit OS'es use a 20bit or 24 bit memory space) would limit the avalibe ram to 1MB (16MB in the case of 24 bit addressing) from the avalible 128/256 MB, while it could be done there would be no reason to artificially limit the hardware. It would be safe to assume that all the OS'es will be 32bit.
Android_x7 said:
you may have misinterpreted what i have said. or you may have not. 16-bit would use less ram and 32-bit would use more ram.
In what way? I have not noticed an increase in RAM usage between 32 and 64 bit intel based OS's, though the reason for compiling at 64 bit was to make more available, the RAM usage per process seemed comparable from memory but I was not measuring particularly.
The fact that 32 or 16 bits at a time can be processed does not mean they are, nor does that change the size of a byte.
I did when I went from XP 32 bit to XP 64 bit years agao my ram useage on the same system went up 5%. But I had more ram than the OS could use so I had no choice. I don't use that OS anymore but at the time it did eat up more ram, and programs compiled for 64 bit had a larger executable file. A 64 bit OS has larger address space to work with so naturally that table alone will consume more ram. Any pointer should become larger because it now contains a 64 bit address instead of a 32 bit address. The variables themselvs don't change the programmer explicitly (well not in all languages) states what size variable he/she wants like long, or double, long long, double double, byte, int, ect.
Only recently did ARM demonstrate a working 64 bit chip, so you can exclude that. A 16 bit OS (Although most 16-bit OS'es use a 20bit or 24 bit memory space) would limit the avalibe ram to 1MB (16MB in the case of 24 bit addressing) from the avalible 128/256 MB, while it could be done there would be no reason to artificially limit the hardware. It would be safe to assume that all the OS'es will be 32bit.
-
Benedict White
- Posts: 224
- Joined: Sat Dec 24, 2011 12:24 am
Re: OS (What bit version is it?)
Jessie, XP doesn't count because it's MS and so I would expect bloat!
Seriously though, 5% is not that great a penalty to pay for actually using the horsepower. I do accept that there is more address space to address, but again as you say, most variables have a set size in bytes. How much difference it makes to memory usage on a tweaked for low RAM system (most Arm systems) is another matter.
I did not know Arm have demonstrated a 64 bit processor, but as far as I am aware their first was 32 bit and that is what they have stuck to so far.
Seriously though, 5% is not that great a penalty to pay for actually using the horsepower. I do accept that there is more address space to address, but again as you say, most variables have a set size in bytes. How much difference it makes to memory usage on a tweaked for low RAM system (most Arm systems) is another matter.
I did not know Arm have demonstrated a 64 bit processor, but as far as I am aware their first was 32 bit and that is what they have stuck to so far.
Re: OS (What bit version is it?)
A 16-bit architecture can only address 64KB of RAM (yes, 65,536 bytes) without special trickery like the old x86 segment/offset junk. 32-bit addressing goes up to 4GB.
Re: OS (What bit version is it?)
A 16-bit architecture can only address 64KB of RAM (yes, 65,536 bytes) without special trickery like the old x86 segment/offset junk. 32-bit addressing goes up to 4GB.
There are plenty of ways to address more than 64 k in a 16 bit memory space. Just the same way a 16 bit processor can process a 32 bit or 64 bit integer or floating point number by using more than one address space. Even the Commodore made a 128k version and there is no x86 going on there.
EDIT: The MOS chip in the C64 was 8-bit so by your statments it should only be able to store 256 bytes of memory. They used a double octet address space so that a more useful (at the time) amount of ram could be utilized, no trickery just engeneering.
The first assumption that you are making is the memory modules that are paired with a 16 bit processor are also 16 bit. But for years modules have been avalible in 32, and 64 bit bus widths. The final assumption is that each element in the memory address space is a byte in size when depending on architecture could also be 16 bit or 32 bit.
-
johnbeetem
- Posts: 945
- Joined: Mon Oct 17, 2011 11:18 pm
- Location: The Mountains
- Contact: Website
Re: OS (What bit version is it?)
OS will be 32-bit. I believe all ARM currently shipping have 32-bit addresses and RasPi's ARM11 is no exception.
Next year we'll probably see products (not RasPi) based on ARM Cortex-A15 and ARM Cortex-A7. They have 32-bit virtual addresses and 40-bit physical addresses. All tasks running on the OS will still be limited to 4GB each, but the operating system can map those physical addresses to 1 TB of memory. This is primarily targeted at servers and desktops. I expect the OS will be 32-bit with 40-bit extension built into the memory mapper.
In a couples of years we'll have ARMv8 which has 32-bit and 64-bit modes.
Next year we'll probably see products (not RasPi) based on ARM Cortex-A15 and ARM Cortex-A7. They have 32-bit virtual addresses and 40-bit physical addresses. All tasks running on the OS will still be limited to 4GB each, but the operating system can map those physical addresses to 1 TB of memory. This is primarily targeted at servers and desktops. I expect the OS will be 32-bit with 40-bit extension built into the memory mapper.
In a couples of years we'll have ARMv8 which has 32-bit and 64-bit modes.
Re: OS (What bit version is it?)
Jessie said:
There are plenty of ways to address more than 64 k in a 16 bit memory space. Just the same way a 16 bit processor can process a 32 bit or 64 bit integer or floating point number by using more than one address space. Even the Commodore made a 128k version and there is no x86 going on there.
Right, like I said, you're not going to get >64K without playing games. At least the x86 allowed you to access all the memory at once in segments. The C=128 had a goofy bank-switching mechanism where there was still only a 64K address space, and global configuration as to how that was partitioned with the available memory and ROM overlays, making interrupt programming a real chore.
The first assumption that you are making is the memory modules that are paired with a 16 bit processor are also 16 bit. But for years modules have been avalible in 32, and 64 bit bus widths. The final assumption is that each element in the memory address space is a byte in size when depending on architecture could also be 16 bit or 32 bit.
Bus widths are completely orthogonal to CPU-addressable widths. The early 68k chips and even the ARM lines have had various implementations where what the processor sees at a register load level is completely removed from both the addressing width and data width of the actual bus & memory chips. The only difference is how much glue is needed to make up for the mismatch. Bus width affects bandwidth, not addressability.
There are plenty of ways to address more than 64 k in a 16 bit memory space. Just the same way a 16 bit processor can process a 32 bit or 64 bit integer or floating point number by using more than one address space. Even the Commodore made a 128k version and there is no x86 going on there.
Right, like I said, you're not going to get >64K without playing games. At least the x86 allowed you to access all the memory at once in segments. The C=128 had a goofy bank-switching mechanism where there was still only a 64K address space, and global configuration as to how that was partitioned with the available memory and ROM overlays, making interrupt programming a real chore.
The first assumption that you are making is the memory modules that are paired with a 16 bit processor are also 16 bit. But for years modules have been avalible in 32, and 64 bit bus widths. The final assumption is that each element in the memory address space is a byte in size when depending on architecture could also be 16 bit or 32 bit.
Bus widths are completely orthogonal to CPU-addressable widths. The early 68k chips and even the ARM lines have had various implementations where what the processor sees at a register load level is completely removed from both the addressing width and data width of the actual bus & memory chips. The only difference is how much glue is needed to make up for the mismatch. Bus width affects bandwidth, not addressability.
Re: OS (What bit version is it?)
What is your point? You said that a 16-bit architechture can only address 64K of ram a couple posts up and that is not true there were 16-bit chips that addressed all the way to 16MB through the use of 24-bit addressing. A 16 Bit chip is not coupled to the fact that it can only address 2^16 worth of memory.
I'm not sure if you just want to argue, and I am not saying that 2^16 isn't 65,536, however, there is nothing wrong with or limiting a engeneer from adding larger memory space to a 16-bit chip.
I see your point about bus width and badwidth, but I don't think there are many people who design a 64-bit bus and have it optimized to make 16-bit transfers. I would bet that any design that uses a 64-bit bus(or any other asymetrical number to 16-bit) is optimized to move 64-bits at a time, and therefore each word stored would be the length of an optimal transfer? Or do you argue that they would store a word size less than the optimal transfer size?
I'm not sure if you just want to argue, and I am not saying that 2^16 isn't 65,536, however, there is nothing wrong with or limiting a engeneer from adding larger memory space to a 16-bit chip.
I see your point about bus width and badwidth, but I don't think there are many people who design a 64-bit bus and have it optimized to make 16-bit transfers. I would bet that any design that uses a 64-bit bus(or any other asymetrical number to 16-bit) is optimized to move 64-bits at a time, and therefore each word stored would be the length of an optimal transfer? Or do you argue that they would store a word size less than the optimal transfer size?
Re: OS (What bit version is it?)
Jessie said:
What is your point? You said that a 16-bit architechture can only address 64K of ram a couple posts up and that is not true there were 16-bit chips that addressed all the way to 16MB through the use of 24-bit addressing.
Huh? What I said is this:
foo said:
A 16-bit architecture can only address 64KB of RAM (yes, 65,536 bytes) without special trickery like the old x86 segment/offset junk.
Android_x7 was saying that going 16-bit would save space. But since a 16-bit address can only address 64K unique addresses, you need to combine multiple registers and store pointers that usually end up being up to 32-bits anyway, since just using plain 16-bit pointers does not get your application very far. All of the tricks to go to 24-bit address spaces requires pointer storage beyond just single 16-bit register values, adds complexity, and is not easily expressed in any sort of compacted way through pointer support in C-like languages (since the pointer could address anywhere in the program's space).
What is your point? You said that a 16-bit architechture can only address 64K of ram a couple posts up and that is not true there were 16-bit chips that addressed all the way to 16MB through the use of 24-bit addressing.
Huh? What I said is this:
foo said:
A 16-bit architecture can only address 64KB of RAM (yes, 65,536 bytes) without special trickery like the old x86 segment/offset junk.
Android_x7 was saying that going 16-bit would save space. But since a 16-bit address can only address 64K unique addresses, you need to combine multiple registers and store pointers that usually end up being up to 32-bits anyway, since just using plain 16-bit pointers does not get your application very far. All of the tricks to go to 24-bit address spaces requires pointer storage beyond just single 16-bit register values, adds complexity, and is not easily expressed in any sort of compacted way through pointer support in C-like languages (since the pointer could address anywhere in the program's space).
Re: OS (What bit version is it?)
What it all comes down to is - the Arm Linux being used is 32 bit. All the available software in repos is 32 bit. All the compilers use 32 bits. There really are no benefits, and lots of disadvantages of using a lower bit depth.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.
Re: OS (What bit version is it?)
There is no such thing as 16-bit on the ARM (even thumb is 32 bit).
As to the memory issues in the future I would imagine that the MMU would be improved to support a larger address space. Like the 32 bit Intel CPUs and PAE, allowing up to a 46 bit address range on all Intel CPUs starting with the P6 generation (and making me wonder why 64 bit is such a big deal). I am using a 32 bit Linux that supports PAE and a motherboard that supports up to 16 GB of RAM on the Intel side. I see no reason that the ARM platforms can not do the same in the future.
As to the memory issues in the future I would imagine that the MMU would be improved to support a larger address space. Like the 32 bit Intel CPUs and PAE, allowing up to a 46 bit address range on all Intel CPUs starting with the P6 generation (and making me wonder why 64 bit is such a big deal). I am using a 32 bit Linux that supports PAE and a motherboard that supports up to 16 GB of RAM on the Intel side. I see no reason that the ARM platforms can not do the same in the future.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers
Re: OS (What bit version is it?)
As John mentioned, the Cortex A15 already does this. Processes are given a 32-bit space within a 40-bit (1TB) maximum address range, and should retain 32-bit binary compatibility. Full 64-bit register modes will come in the iteration after that.
-
liz
- Raspberry Pi Foundation Employee & Forum Moderator
- Posts: 5212
- Joined: Thu Jul 28, 2011 7:22 pm
- Contact: Website
Re: OS (What bit version is it?)
Definitive answer: 32-bit.
Director of Communications, Raspberry Pi
-
Benedict White
- Posts: 224
- Joined: Sat Dec 24, 2011 12:24 am
Re: OS (What bit version is it?)
liz said:
Definitive answer: 32-bit.
I rather thought I'd said that to the OP as his first reply... however, at least now he has been told!
Definitive answer: 32-bit.
I rather thought I'd said that to the OP as his first reply... however, at least now he has been told!
-
liz
- Raspberry Pi Foundation Employee & Forum Moderator
- Posts: 5212
- Joined: Thu Jul 28, 2011 7:22 pm
- Contact: Website
Re: OS (What bit version is it?)
You did, and you did so splendidly; however, I rather noticed that a whole page of speculation had followed on your heels!
Director of Communications, Raspberry Pi
-
Benedict White
- Posts: 224
- Joined: Sat Dec 24, 2011 12:24 am
Re: OS (What bit version is it?)
Some people just need more telling
Re: OS (What bit version is it?)
This discussion is all very worrying for me and re-enforces the need for Raspberry-Pi as far as I am concerned. Do people really not understand what memory is and what it is used for? Discussions on paged memory models are all well and good but to assume longer pointers etc. (much easier to program with than those horrible old MS compiler flags which dictated "Program size") are less efficient than shorter pointers, on the correct hardware, are simply is simply erroneous. Good code and good complier optimization of the software is the key to small tight programs and efficient memory use. Hopefully RPi will engender a better understanding of what really happens when a computer runs!
Fatjonnie
(8k of ferrite core - yes that's kilobytes - in the first "mainframe" I programmed - which in turn was more than the 1k +128 bytes in the i/o chip in the first Acorn I programmed)
Fatjonnie
(8k of ferrite core - yes that's kilobytes - in the first "mainframe" I programmed - which in turn was more than the 1k +128 bytes in the i/o chip in the first Acorn I programmed)
Re: OS (What bit version is it?)
I can tell you from first-hand hiring experience that graduates do come out of universities without knowing the general tradeoffs of using linked lists vs arrays.
Say what they want about not needing to know the low-level bits, but it gives context to being able to actually _use_ the higher level tech competently.
Say what they want about not needing to know the low-level bits, but it gives context to being able to actually _use_ the higher level tech competently.
Re: OS (What bit version is it?)
foo said:
I can tell you from first-hand hiring experience that graduates do come out of universities without knowing the general tradeoffs of using linked lists vs arrays.
Say what they want about not needing to know the low-level bits, but it gives context to being able to actually _use_ the higher level tech competently.
Really? We are in worse shape that I thought, and I thought it pretty bad. I interview people occasionally, most CV's are culled before people come in, and I am continually surprised how badly some people perform even after getting through the culling. And these are people who have been working for a few years. How can you be programming for a few years, and not know anything about linked lists?
I can tell you from first-hand hiring experience that graduates do come out of universities without knowing the general tradeoffs of using linked lists vs arrays.
Say what they want about not needing to know the low-level bits, but it gives context to being able to actually _use_ the higher level tech competently.
Really? We are in worse shape that I thought, and I thought it pretty bad. I interview people occasionally, most CV's are culled before people come in, and I am continually surprised how badly some people perform even after getting through the culling. And these are people who have been working for a few years. How can you be programming for a few years, and not know anything about linked lists?
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.
Re: OS (What bit version is it?)
People follow a bell curve distribution in aptitude in any particular field.
When it comes to software, I believe it's something that's not natural at all to the human brain, so any successful programmer is likely quite off the bell curve to begin with.
Then the fact comes in that you likely want to select out of the top 10%, rather than the other 90%. In any field, a really good practitioner is part of the top 10%, and is hard to find.
And, if you want to be afraid: remember that this holds for other professions. Like lawyers. Or doctors!
That being said, we ask candidates to talk about linked lists versus arrays versus hash tables versus trees in our phone interviews before we interview in person. It does weed out those who don't understand the medium level of programming. (Note: I think arrays and linked lists are medium level -- wiring XML SOAP interfaces together is a lot higher level...)
When it comes to software, I believe it's something that's not natural at all to the human brain, so any successful programmer is likely quite off the bell curve to begin with.
Then the fact comes in that you likely want to select out of the top 10%, rather than the other 90%. In any field, a really good practitioner is part of the top 10%, and is hard to find.
And, if you want to be afraid: remember that this holds for other professions. Like lawyers. Or doctors!
That being said, we ask candidates to talk about linked lists versus arrays versus hash tables versus trees in our phone interviews before we interview in person. It does weed out those who don't understand the medium level of programming. (Note: I think arrays and linked lists are medium level -- wiring XML SOAP interfaces together is a lot higher level...)