microbit@xxxxxxxxxxxxxxxxxxxxxx wrote:
Hi all,
I've already covered all of this in an earlier post, but here goes again
anyway :
On Sat, 07 Nov 2009 15:40:16 +0530, hmthalib <hmthalib@xxxxxxxxx> wrote:
nidhi mittal hada wrote:
Can someone come and please clarify -- it finally
above chain of mail raises more confusion as conflict stays till end.
1)processor 32/64 bit --
a)data it can process at one instance --- register size --- data
bus
size --
OR
b)internal address bus size of processor --- if that is true then
what abt case of pentium 36 bit address lines ---
A processor is called 32 bit or 64 bit depending on the width of the
data bus. not on the register size or data it can process at one
instance
for example a 8 bit micro controller can have 16 bit registers.
similarly all modern processor has architecture to process more data to
increase the throughput.
2)OS 32 /64 bit
a)its virtual address space -- what os provides --- to each process
-- which is mapped to physical address space that prcessor provides
OR
b)processor specifies virtual addr space ??
dont confuse with virtual addr space with physical addr space . MMU will
assist the OS in this issue.
the moment the bit to enable the 64 bit mode is enabled the MMU and
other thing are extend to address 64 bit physical addr space.
3)extra ques -- why in case of 32 bit arch -- physical memory RAM
limitation comes of 4GB ?
because the 32 bit can only address 2^32 address location which is 4GB
of RAM max. where 2^64 = 16 EB (exa bytes)
finally download some data sheet of different processor and read to get
how thing work
On Fri, Oct 23, 2009 at 4:54 PM, <microbit@xxxxxxxxxxxxxxxxxxxxxx
<mailto:microbit@xxxxxxxxxxxxxxxxxxxxxx>> wrote:
Hi,
On Thu, 22 Oct 2009 23:58:20 -0700, C <a.la.kaarta@xxxxxxxxx
<mailto:a.la.kaarta@xxxxxxxxx>> wrote:
>> Well, IMHO the processor does not decide or even know the size
of
>> virtual address space.
> Ofcourse it does. How else do you think it translates a virtual
> address to a physical address? Virtual addresses are simply what
> the
> software 'sees', the processor takes these, translates them into
> physical addresses before making any reads / writes to main
memory. No
> software can use a virtual address space larger than what the
> processor specifies.
>
>> 1) User may run a firmware on the processor that gives a 1-1
>> mapping
>> from virtual to physical (thus making virtual address space
>> equal to
>> physical address space).
>>
> Well, I don't know much about other architectures, so I'll just
comment
on
> x86.
> When you switch to 64bit mode, you compulsorily need to have a
4-level
> paging table, which translates 64-bit linear addresses (actually
a
> 48-bit linear address, since the address is subject to the
> canonical
> address requirement) to (upto) 52-bit physical addresses. So
> irrespective of what firmware you're running, linear addresses
are
> actually 64-bit, but physical addresses are not.
>
> (In fact, physical address space might even be larger than
virtual
> address space, when we take modes like PAE / PSE into account)
>
>> 2) Users may be running different OS(s) that give different
amount of
>> virtual address space to use.
> Irrespective of what OS you're using (and whether it switches to
> the
> processor mode that would utilize the 64-bit virtual address
space
> that the processor provides), the 'internal address bus'
(virtual
> address space) of the processor is what decides the maximum
> virtual
> address space of any programs that run on it (OS or otherwise).
>
> C
>
> On Thu, Oct 22, 2009 at 11:23 PM, Rajat Jain
<Rajat.Jain@xxxxxxxxxxxx <mailto:Rajat.Jain@xxxxxxxxxxxx>>
> wrote:
>>
>> Hi,
>>
>> ----Original Message----
>> From: C [mailto:a.la.kaarta@xxxxxxxxx
<mailto:a.la.kaarta@xxxxxxxxx>]
>> Sent: Friday, October 23, 2009 10:51 AM
>> To: Rajat Jain
>> Cc: simonyanix@xxxxxxxxx <mailto:simonyanix@xxxxxxxxx>; Siddu;
Rick Brown; kernelnewbies;
>> linux-newbie@xxxxxxxxxxxxxxx
>> <mailto:linux-newbie@xxxxxxxxxxxxxxx>
>> Subject: Re: 32 bit processors / 64 bit processors
>>
>>> PAE (Physical Address Extension) expands the _physical_
address
space
>>> to > 32 bits, but the _virtual_ address space stays the same
at
>>> 32-bits, and the virtual address size is what I mentioned as
qualifies
>>> the processor as 32-bit or 64-bit.
>>
>> Well, IMHO the processor does not decide or even know the size
of
>> virtual address space.
> Ofcourse it does. How else do you think it translates a virtual
> address to a physical address?
>
> It purely depends on the software (OS in this
>> case) that runs on it. Consider all of the following is
possible
on the
>> same 32 bit processor:
>>
>> 1) User may run a firmware on the processor that gives a 1-1
>> mapping
>> from virtual to physical (thus making virtual address space
>> equal to
>> physical address space).
>>
>> 2) Users may be running different OS(s) that give different
amount of
>> virtual address space to use.
>>
>> What am I missing?
>>
>> Thanks,
>>
>> Rajat
>>
>>
>>>
>>> 1. Addressable physical memory / physical address size does
not
decide
>>> whether a processor is 32-bit / 64-bit, there is no processor
(AFAIK)
>>> which can address 64 bits of physical memory. I suppose
sizeof(void*)
>>> gives you the size of the _virtual_ address, so yes, I suppose
>>> that
>>> should be 64 bits on a 64-bit processor (and using a 64-bit
compiler)
>>> 2. Register size does not decide whether a processor is 32-bit
/
>>> 64-bit.
>>>
>>> C
>>>
>>> On Thu, Oct 22, 2009 at 10:05 PM, Rajat Jain
>>> <Rajat.Jain@xxxxxxxxxxxx <mailto:Rajat.Jain@xxxxxxxxxxxx>>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>>> 1. The size of the processor's internal address bus (virtual
address
>>>>> space) is what qualifies it as a 32-bit / 64-bit processor.
>>>>
>>>> Well, in that sense, isn't Pentium a "36-bit" processor
(since
>>>> it
>>>> gives the option of PAE to use 64 GB of memory - it must be
>>>> having
>>>> atleast 36 address lines)?
>>>>
>>>> On this topic and in this thread, we have had following
responses to
>>>> the question on what is called a 32-bit or 64-bit processor:
>>>>
>>>> 1) Addressable Physical memory (=sizeof(void*))
>>>> 2) Register Size (=instruction size)
>>>>
>>>> Are the above two independent of each other? If yes, then how
do we
>>>> deine a processor as 32-bit / 64-bit?
>>>>
>>>> Thanks,
>>>>
>>>> Rajat
>>
>
> --
> To unsubscribe from this list: send an email with
> "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
<mailto:ecartis@xxxxxxxxxxxx>
> Please read the FAQ at http://kernelnewbies.org/FAQ
>> Well, IMHO the processor does not decide or even know the size
of
>> virtual address space.
> Ofcourse it does. How else do you think it translates a virtual
No it doesn't... the previous poster is right. (unless we
excessively get
into semantics....)
That is up to the MMU, it has absolutely nothing to do with the
CPU.
And FWIW, x86 is hardly a reference... x86, along with 8051 would
have to
be the biggest abonimation
to the concept of elegant processing......
-- Kris
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
<mailto:ecartis@xxxxxxxxxxxx>
Please read the FAQ at http://kernelnewbies.org/FAQ
--
Thanks & Regards
Nidhi Mittal Hada
A processor is called 32 bit or 64 bit depending on the width of the
data bus. not on the register size or data it can process at one
instance
NO, that is NOT correct !
I did notice that you clarified in a later post by implying the term
'internal data bus'.
That's considered more correct...
Many 32 bit CPUs can/will for example interface with only a 16 or even 8
bit data bus. (eg. extreme example, NAND Flash).
It's up the vendor of the ASIC/SoC to choose the width of the internal
data bus.
Micro code canstill sacrifice CPU cycles for fetching data, and hence for
example only use an internal 16 bit data bus when the ALU is 32 bits.
The only way to qualify the _native_ bit width of a CPU is by its ALU.
Period.
As I posted much earlier, some CPUs can have wider registers than the
actual ALU bit width and vice-versa.
Or some can even use many ALUs to operate concurrently. But of course
there it gets more ambiguous.
(that gets into super scalar thin ice :-)
The bottom line is that the native bit width is the width of the ALU, the
data bus width is irrelevant.
If the actual CPU needs more cycles to do a "native" data operation, then
that is irrelevant from the code's point of view
(IOW from the compiler or user's point of view).
So to summarise, not even the internal data bus on the silicon
should/would determine the native data size, or at least, not necessarily.
The ALU determines this.
B rgds
Kris
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
Hi Kris,
What you told makes more sense. may be I have check out. but AFAIK
reading though the datasheets of the processor mostly they simply say
data bus = processor default width size. but still your are correct.
Thanks for your clarification.
--
Regards,
Mohamed Thalib H
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
