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
"Mohamed Ghouse , Gurgaon" <[email protected]> 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
[email protected]
Also sprach M?ns Rullg?rd:
> "Mohamed Ghouse , Gurgaon" <[email protected]> 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
> [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> 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
=?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
[email protected] (Johannes Ruscheinski) writes:
> Also sprach M?ns Rullg?rd:
> > "Mohamed Ghouse , Gurgaon" <[email protected]> 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
[email protected]
"Albert D. Cahalan" <[email protected]> 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
[email protected]
On 2 Jul 2002, [iso-8859-1] M?ns Rullg?rd wrote:
> "Albert D. Cahalan" <[email protected]> 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.
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
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------
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
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.