hi, have a user running some fortran software and the program asks to input the amount of memory that is available in the system that the program can use.
But the way it asks is: specify the amount of memory in words.

so my question is, how much is a word of memory?
I haven't done any of the math but I trust the user and she has worked the numbers every which way and nothing seems to add up.
The system is running SLES 10, ia64, has 64 GB of RAM, upon a reboot doing a top we see 1 GB of ram used and 63 GB free.

appears to be 16 bits or two bytes for X86 Architecture..
http://en.wikipedia.org/wiki/Word_(computing)

I believe the IA64 architecture uses 64 bit words.

From: http://en.wikipedia.org/wiki/Word_(computer_science)
For what we call X86, that would be 32 bits. For AMD64/X86_64 that would be 64 bits.

The concept of "word" is defined as a group of bytes with some internal significance and that can be handle as a sole entity by the machine. So, when you send or read something to/from a cpu registry or the ram of your machine, you read a or write a word usually. This depends on the architecture of the system though.

All the x86-compatible cpu's support a 16 bits word size, but they can work with greater word sizes.

For me, the word size is defined by the assembly code of a given application. The max size of the registers you use define the word size. On 80386 and avove this can be 32 bits. On x86_64 capable cpu's this can be 64. Note that I say "can be", and not "is".

It depends on the mode you use your cpu. If you use a 64 bits OS, then your word size will be 64 bits because the object code of your programs will use 64 bits registers. If you use an OS compiled for x86, then the word size will be 32 bits, since that's what your object code will look like.

AFAIK, ia64 is Itanium and all Itaniums are 64-bit processors so the word size is 64 bits. On x86_64 it can vary depending on whether the kernel is 32-bit or 64-bit, therefore whether the processor is running in 32-bit or 64-bit mode.

Ops, you are right. If by ia64 he means Itanium, then the word size is always 64, unlike in amd64/x86_64.

It seems to me that the hairs are being split a bit too fine when a compatibility mode is equated to the kernel's native mode. Can the x86 (i.e. 32-bit native) kernel run 16-bit or 8-bit programs in any compatibility mode, such as for wine?

I am not familiar enough with the wine internals to answer that question. What linux runs is wine, how wine hooks up the whole thing is another question that I cannot answer.

There's no need either. Putting a similar example, and x86_64 kernel can run wine (a 32 bits binary itself, since wine doesn't compile in x86_64 natively), so yes, the kernel can use smaller word sizes when necessary I guess. In any case note that the x86/amd64 case is very special, since the cpu can run natively that code even when working on 64 bits mode. The IA32 emulation option must be on for that to work when you compile your kernel, but there's little "emulation" involded since it's really the cpu which supports the whole thing.

Yes. The OS can be able to run programs with a smaller word size. But if someone ask me "which is the word size for a given architecture?" then I would answer that it is the word size that's native to that architecture, regardless on how much backwards compatibility has been preserved, in amd64, I say it's 64 bits.

However, I am not the kind of user who reads all the technical papers for each released cpu, and it's long since I used assembler for anything (as long as on a 486 cpu, so...).

To add even more complication to this question, doesn't 32 bit mode support 64 bit data addressing with the PAE extensions option turned on for those processors that support PAE?

And to make it even more complicated: http://en.wikipedia.org/wiki/X86-64
So, perhaps the answer is: It depends on which processor your using, what mode it's running in, AND what compiler options you chose when you compiled your program.

From the point of view of the query in the fortran program:

"Specify the amount of memory in words".

Most likely to the fortran programmer, the 'word' means the space occupied by a standard integer (or real) element - perhaps needed for array sizing etc.
As stated by several others this will vary with hardware, compiler, compiler options etc.
One pragmatic way to check your assumptions on these variables might be compile a simple program as below using exactly same compiler options as your application program.

Compile and run first like this and then with lines 2,4 commented out (removing the array stuff)
On my standard 32 bit linux box, I see a change in virtual memory usage of 3912 kb (using top) between the 2 cases. This tells me that each integer is definitely occupying:

3912kb*1024/1000000 = 4 bytes.

(PS To see the memory used by the data array, you actually have to be using the array - hence the while statement -
Hence this will hog the CPU so dont try while others are using the machine!)

Steve

In x86_64 I think it all depends on the kernel which sets the processor to 32-bit or 64-bit mode. With emulation all it does is expand 32-bit to 64-bit and send that to the processor. The same thing would be done with wine, convert 8-bit or 16-bit to 32-bit send that to the kernel, kernel coverts it to 64-bit sends to processor ... lots of converting going on, probably will produce some performance overhead, not that it matters for 8-bit or 16-bit programs.

You didn't read my link, did you? Exactly what emulation do you imagine is going on in the kernel? The kernel doesn't perform math functions or memory reads and writes. There is no such converting going on, but this is not the place to argue over it, I suppose.

I wasn't completely off, take a look at the Operating modes table in your link.

I understand that, but what you were describing was an interpreted environment. Linux is not one. The kernel gets control with either a call to a kernel function or from an interrupt such as timer or execution exception. If the opcode is illegal in the running mode, then of course the kernel will get an interrupt. Other than that, no, the code just runs to whatever conclusion. I can see that jumps and calls would be an issue, they always are, so that's why there is the compatibility package. But accessing data and performing an action on it, I don't see it, and I believe that's what the question of the size of a word pertains to. Consider that your program can still access data on the byte level in a 64 bit environment. Hmm, the code for doing 64 bit math has been around for a long time, even in the 16 bit environment, though it wasn't native access, and IIRC used memory accumulators and multiple registers.