Word size

[Neo]

Is there any way we can find the word size of a Processor and/or the OS? (without referring to the docs that is)

[aladdin]

i think that the only way is to detect the processor type then to get word size from docs or CPU specifications

[aladdin]

or maybe u can try to put the maximum value on a register then calculate how many bits it holds.

Code: Select all

xor  reg, reg    ;put 0 in reg
dec reg           ;put 1111111.....b in reg
;then calculate how many bits there is 

[Pype.Clicker]

@aladin, that'd make no sense: if you issue opcode for "dec AX", you will not alter bits 16-31 of a 32bits machine ... And if you use "dec eax", you will not alter bits 32-63 of a 64bits machine.

The opcode you give to the processor *tells* the word size to be used. However, i'd expect CPUID to tell you how that through extension flags.

from /usr/src/linux/include/asm/cpufeature.h

Code: Select all

#define X86_FEATURE_IA64        (0*32+30) /* IA-64 processor */
#define X86_FEATURE_LM          (1*32+29) /* Long Mode (x86-64) */

32 bits processors have a sticky bit somewhere in flags that ppl can check to know if it's 386+ or 286-only processor around.

[smiddy]

Is there any way we can find the word size of a Processor and/or the OS? (without referring to the docs that is)

I'm unsure what you're asking. A word is described as two-bytes on every processor I've encountered. A byte is eight bits and a nibble is four bits. A double word is four-bytes and a quatenary-word is eight-bytes.

If you are wondering how to determine the size of the registers then, for x86 types, using a method of determining the processor like CPUID can help you to determine the register size used. On Motorola type processors I am unfamiliar. Certain embedded processors don't have a way to determine them,so you would devlope directly for that platform (using documentation).

Of course, since I'm uncertain for sure what you're asking then perhaps I am off base. Please specify what you are requestiing.

[Pype.Clicker]

A word is described as two-bytes on every processor I've encountered.

Then you may not have encountered SPARC processor yet, nor those ancient exotic 36-bits word machines. And the "dword" and "quadword" you're refering are much intel-specific, afaik.

"Word" is a vague term wich usually refers to the "native integer that the ALU can process at once" ... Since natively-speaking, x86 is a 16bits (then extended) family, "word" has initially referred to a 16bits quantity, but on machines like SunSparc (see mindhack.cebuano.org), 'word' is 32 or 64 bits ...

The most "portable" way to tell is to ask your compiler how large is an "int" (and assume you're using a correctly-configured compiler

[mpp.eox3]

@aladin, that'd make no sense: if you issue opcode for "dec AX", you will not alter bits 16-31 of a 32bits machine ... And if you use "dec eax", you will not alter bits 32-63 of a 64bits machine.

Hmm that's right :). But what about this:

int i = 0;
--i;
// count the bits

int should be word-size (note: non intel specific usage of the word "word") on every type of processors, ensured by the compiler.

[distantvoices]

bit counting might be easier done with the "bsr" or "bsl" instructions - at least on i386 processors.

[smiddy]

A word is described as two-bytes on every processor I've encountered.

Then you may not have encountered SPARC processor yet, nor those ancient exotic 36-bits word machines. And the "dword" and "quadword" you're refering are much intel-specific, afaik.

This is true, however most course today will use what I said as gospel.

"Word" is a vague term wich usually refers to the "native integer that the ALU can process at once" ... Since natively-speaking, x86 is a 16bits (then extended) family, "word" has initially referred to a 16bits quantity, but on machines like SunSparc (see mindhack.cebuano.org), 'word' is 32 or 64 bits ...

Yeah, I agree, it is very vague depending on your platform and especially the layer of thinking we're talking. I expect that the original question was compiler specific. As you point out below, that being why I was confused and asking for specifics ;D

The most "portable" way to tell is to ask your compiler how large is an "int" (and assume you're using a correctly-configured compiler

[Pype.Clicker]

Code: Select all

  unsigned int i=0;
  unsigned bits=0;
  for (--i;i;bits++,i=i>>1);
  kprint("running on a %i-bits system",bits);

Well, that'll behave much the same than

Code: Select all

  kprint("compiled on a %i-bits system",sizeof(int)*8);

e.g. if the compiler isn't tuned for x86-64 instructions, for instance, it will use a 32bits shifting operation and decreasing operation to perform "--i" or "i=i>>1", thus failing to discover it's running on a 64 bits system.

The same program (bitwise.c, collecting code above), either compiled on a 32bits system (./bitwise) or on a 64bits system (./bitwise64) give the following results on a x86-64 AMD system

goliath /home/martin> ./bitwise64
running on a 64-bits system (runtime)
compiled on a 64-bits system
goliath /home/martin> ./bitwise
running on a 32-bits system (runtime)
compiled on a 32-bits system

This is true, however most course today will use what I said as gospel.

Which confirms most course today are biased ...

[aladdin]

what about counting a pointer size in bits, I think pointer size is equal to word size.
but i m not sure if its a memory word or a CPU word

if this can be used we should declare a null pointer then decrease it and count bits

[Pype.Clicker]

what about counting a pointer size in bits, I think pointer size is equal to word size.
but i m not sure if its a memory word or a CPU word

This will, once again, tell you what the *compiler* assumes from the CPU you're running on, not what the CPU itself is capable of.

[Neo]

Yeah determining the compilers would not be too difficult but the CPU's word size......... :-\
Maybe That CPUID method is the best bet so far?

[smiddy]

Yeah determining the compilers would not be too difficult but the CPU's word size......... :-\
Maybe That CPUID method is the best bet so far?

That would be my assessment. You would have to hard code for the specific platform you're on based on determination of the processor you find by CPUID or whatever the function is on the processor you're coding for, then use optimaized code accordingly.

Quote:
This is true, however most course today will use what I said as gospel.


Which confirms most course today are biased ...

Yeah, the philosophy of the propaganda pushed due to information dominance... ;D I get the hint that this is annoying you. Sorry, I don't intend to. Given the exigence will determine the definition used. If all encompassing is the presribed agenda then it is necessary to open up full disclosure about the permutation of possibility. However, given the scope of what has been presented up to this point then a rudimentary explanation would suffice, no? We could also delve into paragraphs too, but then there are so many possibilities. Which would perhaps waste type face on these pages, I expect.