Diff b/w 32bit & 64-bit

Diff b/w 32bit & 64-bit

[Mohamed Ghouse , Gurgaon]

Hello All
 I am working on a Driver.
Considering the processor 2 B Intel's x86, 
can some one enlighten me with the differences of Linux on a 64-bit
processor & a 32-Bit processor.

TIA
-Ghouse

Re: Diff b/w 32bit & 64-bit

[Måns Rullgård]

"Mohamed Ghouse , Gurgaon" <MohamedG@ggn.hcltech.com> writes:

> Hello All
>  I am working on a Driver.
> Considering the processor 2 B Intel's x86, 
> can some one enlighten me with the differences of Linux on a 64-bit
> processor & a 32-Bit processor.

For Alpha: sizeof(int) == 4, sizeof(long) == 8, sizeof(void *) == 8
For intel: sizeof(int) == 4, sizeof(long) == 4, sizeof(void *) == 8

The most common mistake is trying to stuff a pointer into an
int. Don't do that.

-- 
Måns Rullgård
mru@users.sf.net

Re: Diff b/w 32bit & 64-bit

[Johannes Ruscheinski]

Also sprach M?ns Rullg?rd:
> "Mohamed Ghouse , Gurgaon" <MohamedG@ggn.hcltech.com> writes:
> 
> > Hello All
> >  I am working on a Driver.
> > Considering the processor 2 B Intel's x86, 
> > can some one enlighten me with the differences of Linux on a 64-bit
> > processor & a 32-Bit processor.
> 
> For Alpha: sizeof(int) == 4, sizeof(long) == 8, sizeof(void *) == 8
> For intel: sizeof(int) == 4, sizeof(long) == 4, sizeof(void *) == 8
                                                  ^^^^^^^^^^^^^^^^^^^
I don't know where you come up with that.  On x86 Linux the size of
any pointer is 4 bytes!
> 
> The most common mistake is trying to stuff a pointer into an
> int. Don't do that.
> 
> -- 
> M?ns Rullg?rd
> mru@users.sf.net
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Johannes
--
Dr. Johannes Ruscheinski
EMail:    ruschein_AT_infomine.ucr.edu ***          Linux                  ***
Location: science library, room G40    *** The Choice Of A GNU Generation! ***
Phone:    (909) 787-2279

"Faith may be defined briefly as an illogical belief in the occurrence of the improbable...
 A man full of faith is simply one who has lost (or never had) the capacity for clear and
 realistic thought. He is not a mere ass: he is actually ill."
               -- H. L. Mencken

Re: Diff b/w 32bit & 64-bit

[Måns Rullgård]

ruschein@mail-infomine.ucr.edu (Johannes Ruscheinski) writes:

> Also sprach M?ns Rullg?rd:
> > "Mohamed Ghouse , Gurgaon" <MohamedG@ggn.hcltech.com> writes:
> > 
> > > Hello All
> > >  I am working on a Driver.
> > > Considering the processor 2 B Intel's x86, 
> > > can some one enlighten me with the differences of Linux on a 64-bit
> > > processor & a 32-Bit processor.
> > 
> > For Alpha: sizeof(int) == 4, sizeof(long) == 8, sizeof(void *) == 8
> > For intel: sizeof(int) == 4, sizeof(long) == 4, sizeof(void *) == 8
>                                                   ^^^^^^^^^^^^^^^^^^^
> I don't know where you come up with that.  On x86 Linux the size of
> any pointer is 4 bytes!

Of course it's 4, that's the point. My mistake, sorry if I confused
anyone.

-- 
Måns Rullgård
mru@users.sf.net

Re: Diff b/w 32bit & 64-bit

[Albert D. Cahalan]

=?iso-8859-1?q?M=E5ns_Rullg=E5rd?= writes:

> For Alpha: sizeof(int) == 4, sizeof(long) == 8, sizeof(void *) == 8
> For intel: sizeof(int) == 4, sizeof(long) == 4, sizeof(void *) == 8

That second line is _only_ correct for Win64.
The Linux way:

char is 8 bits
char may be signed or unsigned by default
short is 16 bits
int is 32 bits
long is the name number of bits as a pointer
long is either 32 bits or 64 bits
long long is 64 bits
don't cast from "foo *" to "bar *" if sizeof(foo)<sizeof(bar)
in a struct, put big items first to avoid padding
don't use "long" in a struct that goes to disk or over the network
with few exceptions, floating-point math in the kernel is prohibited
don't assume that all physical memory is continuously mapped
don't assume that you can DMA to any address you like

Re: Diff b/w 32bit & 64-bit

[Måns Rullgård]

"Albert D. Cahalan" <acahalan@cs.uml.edu> writes:

> =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= writes:
> 
> > For Alpha: sizeof(int) == 4, sizeof(long) == 8, sizeof(void *) == 8
> > For intel: sizeof(int) == 4, sizeof(long) == 4, sizeof(void *) == 8
> 
> That second line is _only_ correct for Win64.

As I said, I typed the wrong key. It would make no sense otherwise.

-- 
Måns Rullgård
mru@users.sf.net

Re: Diff b/w 32bit & 64-bit

[Richard B. Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=US-ASCII, Size: 739 bytes --]

On 2 Jul 2002, [iso-8859-1] Måns Rullgård wrote:

> "Albert D. Cahalan" <acahalan@cs.uml.edu> writes:
> 
> > =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= writes:
> > 
> > > For Alpha: sizeof(int) == 4, sizeof(long) == 8, sizeof(void *) == 8
> > > For intel: sizeof(int) == 4, sizeof(long) == 4, sizeof(void *) == 8
> > 
> > That second line is _only_ correct for Win64.
> 

"Win64"?? Do you mean that M$ now takes credit for SEGMENT:OFFSET?
Good! That'll keep 'em in their place!  Seriously, I think it's
really Win48 --another Windows distortion. Segment descriptor is
16 bits and the offset remains 32.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: Diff b/w 32bit & 64-bit

[Jamie Lokier]

Albert D. Cahalan wrote:
> don't cast from "foo *" to "bar *" if sizeof(foo)<sizeof(bar)

What is the reason for this?  I do it quite routinely ("poor man's
inheritance").

cheers,
-- Jamie

Re: Diff b/w 32bit & 64-bit

[Thunder from the hill]

Hi,

On Sun, 7 Jul 2002, Jamie Lokier wrote:
> > don't cast from "foo *" to "bar *" if sizeof(foo)<sizeof(bar)
> 
> What is the reason for this?  I do it quite routinely ("poor man's
> inheritance").

This should only be OK if you pad bar before.

The reason is this one:
foo:
[00111001000011111101001010010101]
(bar *)foo
[00111001000011111101001010010101xunpredictablex]

							Regards,
							Thunder
-- 
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o?  K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y- 
------END GEEK CODE BLOCK------

Re: Diff b/w 32bit & 64-bit

[Jamie Lokier]

Thunder from the hill wrote:
> > > don't cast from "foo *" to "bar *" if sizeof(foo)<sizeof(bar)
> > 
> > What is the reason for this?  I do it quite routinely ("poor man's
> > inheritance").
> 
> This should only be OK if you pad bar before.

Erm, crossed wire :-)

I do it for inheritance in the same way as, say, Xlib with X events.
That's perfectly safe and commonplace.

I didn't understand Albert's reason for prohibiting the mere cast.
(Notions of old machines where the char * representation is different
from int * came to mind, but Linux doesn't run on those... does it?)

Oliver Neukum explained that you shouldn't dereference a pointer to a
larger type because of alignment issues on some machines.
sizeof(foo)<sizeof(bar) captures this rule just fine for the basic data
types (char, int etc.).

But for structures, it's actually possible to have a smaller type with a
larger alignment requirement, and vice versa:

     struct small { double x; };
     struct large { char y [11]; };

Also, it is certainly permitted to cast "char *" to "int *" if you know
that the underlying object is an "int" or something compatible with one.

So, the general rule `don't cast from "foo *" to "bar *" if
sizeof(foo)<sizeof(bar)' is wrong, and is routinely not followed.

An alternative rule might be `never dereference a "bar *" if it might
not have the correct alignment for "bar" on any platform'.

-- Jamie

Re: Diff b/w 32bit & 64-bit

[Albert D. Cahalan]

Jamie Lokier writes:

>>>> don't cast from "foo *" to "bar *" if sizeof(foo)<sizeof(bar)
...
> Oliver Neukum explained that you shouldn't dereference a pointer to a
> larger type because of alignment issues on some machines.
> sizeof(foo)<sizeof(bar) captures this rule just fine for the basic data
> types (char, int etc.).

Yes, that was the intent.

> But for structures, it's actually possible to have a smaller type with a
> larger alignment requirement, and vice versa:
>
>      struct small { double x; };
>      struct large { char y [11]; };
>
> Also, it is certainly permitted to cast "char *" to "int *" if you know
> that the underlying object is an "int" or something compatible with one.
>
> So, the general rule `don't cast from "foo *" to "bar *" if
> sizeof(foo)<sizeof(bar)' is wrong, and is routinely not followed.
>
> An alternative rule might be `never dereference a "bar *" if it might
> not have the correct alignment for "bar" on any platform'.

Got a shorter way to say that? In less than one line, give
a rule that will keep x86-centric programmers from getting
hurt by the alignment restrictions.