Since standard C doesn't provide any way for the programmer to direct
the compiler as to how to layout structures, most compilers provide some
way to do this, albeit in different forms.
Microsoft (and lcc-win) uses
#pragma pack(1)
Gcc uses
__attribute__ {(packed)}
Has anyone seen other directives in other compilers?
Specifically, Microsoft allows to pack structures with some integer
constant (pack(2) for instance), but gcc doesn't seem to allow this.
What other semantic differences could exist there?
I am writing this part of my tutorial, and I would like to make a table
about the constructs used by the various compilers. Note that under
windows you must know this kind of stuff since windows uses packed
structures extensively.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Dec 3 '07
76  4001 
Flash Gordon wrote:
jacob navia wrote:
.... snip ...
>
>I am writing this part of my tutorial, and I would like to make a
table about the constructs used by the various compilers. Note that
under windows you must know this kind of stuff since windows uses
packed structures extensively.
If the library headers are written properly then you should not
need to know about the packing because just including win.h (or
whatever) should sort it all out for you.
win.h!! There is no such header mentioned in the C standard. Are
you seriously suggesting letting Microsoft sort things out
anywhere? anytime?
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
Tor Rustad <to********@hotmail.comwrites:
[...]
IMO, "packing" should be avoided anyway. On architectures with
alignment requirements, it's a terrible idea to use e.g.
#pragma pack(1)
"If you use #pragma pack to align struct or union members on
boundaries other than their natural boundaries, accessing these fields
usually leads to a bus error on SPARC."
- http://docs.sun.com/app/docs/doc/819...&a=view&q=pack
I've already expressed my opinion of this behavior (that it's a bug,
even if it's not a violation of the standard).
Furthermore, it's a rather bad idea on most RISC architectures, it's a
fault. The system may, or may not mask the fault. Typically, unaligned
access will *at least* give a performance penalty, as it do on x86.
Windows, typically mask such alignment faults on the x86 by default,
except for [1]. However, this don't always need to be the case, for
e.g. MIPS, the MSDN doc state an explicit Win32 call was needed:
SetErrorMode(GetErrorMode() | SEM_NOALIGNMENTFAULTEXCEPT);
to make Windows automatically do the fix-up on alignment faults.
MIPS is a rather exotic case, but programmers shouldn't expect that
x64 will be so forgiving to alignment faults, as x86 has been. Don't
be surprised if the penalty become significant bigger in this case.
In my opinion, if a compiler is going to support structure members
that don't have the alignment for the member's type, it's the
compiler's job to generate code that will access that member in a way
that (apart from performance and code size) is indistinguishable from
accessing an aligned member.
On an x86, as I understand it, the compiler can just generate code to
access the member normally, and it's handled in hardware.
On a SPARC, the compiler can, for example, do the equivalent of
memcpy() to copy the unaligned member to or from an aligned temporary.
Or maybe it can access it directly and clean up after the fault. The
language, or the extension, doesn't need to specify *how* this is
done, just that it needs to be done properly.
Blindly trying to access the member as if it were aligned, when the
compiler itself chose to misalign it (in response to a pack pragma) is
just dumb.
I've worked in languages that have the equivalent of packed
structures, and this is what they do.
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
CBFalconer wrote:
REH wrote:
>CJ <nos...@nospam.invalidwrote:
>>jacob navia wrote:
o References to fields in packed structures may be less
efficient than references to fields in unpacked structures.
That is obvious too.
What would be nice is that standard C would allow this to be
defined in the language, with well defined semantics.
Rubbish. Packing for structs is an implementation detail, and any
program relying on such details will be inherently non-portable.
Why is this non-portable? The Ada standard (and, thus, compilers)
have done this portably for years.
The last time I looked there were considerable differences between
the C standard and the Ada standard. I see no reference to packing
in the C standard.
This also illustrates the foolishness of discussing non-standard
compiler features in this newsgroup.
The issue was not whether the C standard currently supports it; the
issue was whether the C standard could be modified to support it. Note
the key phrase "What would be nice is that standard C would allow this
....". That's the subjunctive mood (incorrectly handled, but mishandling
the subjunctive mood is something that even native speakers of English
often do).
CJ responded directly and negatively to that statement with an assertion
that this feature is inherently non-portable. If by "non-portable" he
meant that the C standard didn't currently support this feature, then
his comment was a non-sequitur. I assume that this was not CJ's intent.
Assuming that CJ understood what Jacob was saying, and was actually
attempting to be rationally responsive to Jacob's comment, the only
reasonable interpretation was that CJ was asserting that this feature
would be so inherently non-portable as to prevent such a modification of
the standard.
In that case, pointing out that the Ada standard does support such a
feature is entirely relevant: it proves that it is possible for a
computer language standard to support such a feature; how much
modification of the C standard would be needed to achieve that same goal
is yet to be determined.
James Kuyper wrote:
CBFalconer wrote:
>REH wrote:
>>CJ <nos...@nospam.invalidwrote:
jacob navia wrote:
> o References to fields in packed structures may be less
> efficient than references to fields in unpacked structures.
That is obvious too.
>
What would be nice is that standard C would allow this to be
defined in the language, with well defined semantics.
Rubbish. Packing for structs is an implementation detail, and any
program relying on such details will be inherently non-portable.
Why is this non-portable? The Ada standard (and, thus, compilers)
have done this portably for years.
The last time I looked there were considerable differences between
the C standard and the Ada standard. I see no reference to packing
in the C standard.
This also illustrates the foolishness of discussing non-standard
compiler features in this newsgroup.
The issue was not whether the C standard currently supports it; the
issue was whether the C standard could be modified to support it. Note
the key phrase "What would be nice is that standard C would allow this
...". That's the subjunctive mood (incorrectly handled, but
mishandling the subjunctive mood is something that even native
speakers of English often do).
I suppose that would be: "What would be nice is for standard C to
allow..."
CJ responded directly and negatively to that statement with an
assertion that this feature is inherently non-portable. If by
"non-portable" he meant that the C standard didn't currently support
this feature, then his comment was a non-sequitur. I assume that this
was not CJ's intent. Assuming that CJ understood what Jacob was
saying, and was actually attempting to be rationally responsive to
Jacob's comment, the only reasonable interpretation was that CJ was
asserting that this feature would be so inherently non-portable as to
prevent such a modification of the standard.
In that case, pointing out that the Ada standard does support such a
feature is entirely relevant: it proves that it is possible for a
computer language standard to support such a feature; how much
modification of the C standard would be needed to achieve that same
goal is yet to be determined.
I suspect that it would be harder for the C standard to incorporate this
feature than for Ada, since the C standard attempts to be portable to a
wider range of machines than Ada. Also this might go against C's spirit
of being as efficient as possible and assuming that the programmer
knows what he is doing.
CJ wrote:
>
On 3 Dec 2007 at 22:23, jacob navia wrote:
There is no keyword added:
#pragma is used for precisely that: unportable compiler directives.
gcc uses __attribute__ anyway in many other situations.
Yes, and relying on this sort of thing is a bad idea if you're trying to
write portable code.
Sometimes you have to write non-portable code. For example, when
passing structs to system APIs. The system and/or the runtime
library requires the struct to have specific alignments. If you
allow (even via command-line flags as you suggest) a method of
changing the alignment, then you must supply a method of local
overrides.
[...]
It means that the statement you made was obviously nonsense, and badly
thought-out.
OK. You have thought it out better than gcc/microsoft/sun/sgi/.
Probably gcc/etc. want to allow the programmer to decide *for each
individual struct* whether it should be packed or not. This approach
will create terrible maintenance headaches - the pack/don't pack
directive will need to be present each time the compiler sees a
declaration of the struct.
Unless you forbid any changes in alignment, then you are correct.
However, you then run into problems when calling system API calls
which require a specific alignment on their structs.
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
On Dec 5, 9:15 am, santosh <santosh....@gmail.comwrote:
James Kuyper wrote:
I suspect that it would be harder for the C standard to incorporate this
feature than for Ada, since the C standard attempts to be portable to a
wider range of machines than Ada. Also this might go against C's spirit
of being as efficient as possible and assuming that the programmer
knows what he is doing.
Why do you assume that C attempts to be "more portable" than Ada.
What are you basing your assertion on? What you do portably in C than
cannot be done in Ada?
REH
On Dec 5, 3:23 pm, REH <spamj...@stny.rr.comwrote:
On Dec 5, 9:15 am, santosh <santosh....@gmail.comwrote:
James Kuyper wrote:
I suspect that it would be harder for the C standard to incorporate this
feature than for Ada, since the C standard attempts to be portable to a
wider range of machines than Ada. Also this might go against C's spirit
of being as efficient as possible and assuming that the programmer
knows what he is doing.
Why do you assume that C attempts to be "more portable" than Ada.
What are you basing your assertion on? What you do portably in C than
cannot be done in Ada?
REH
Oops, sorry. My poor editing made the above appear as if I am quote
James Kuyper. I apologize James.
REH
CBFalconer wrote, On 05/12/07 01:33:
Flash Gordon wrote:
>jacob navia wrote:
... snip ...
>>I am writing this part of my tutorial, and I would like to make a
table about the constructs used by the various compilers. Note that
under windows you must know this kind of stuff since windows uses
packed structures extensively.
If the library headers are written properly then you should not
need to know about the packing because just including win.h (or
whatever) should sort it all out for you.
win.h!! There is no such header mentioned in the C standard. Are
you seriously suggesting letting Microsoft sort things out
anywhere? anytime?
Yes, I expect them to sort out their headers so that you can include
them and use their API without having to litter your own code with pack
directives even if every structure used in the API requires different
packing. I strongly suspect that MS actually do this (I've seen code use
the Windows API without messing about with packing), and the one time I
found it being done incorrectly it was in a header provided by a third
party for Borland C++ builder, so MS were responsible for neither the
header nor the compiler.
--
Flash Gordon
jacob navia wrote:
CJ wrote:
>Rubbish. Packing for structs is an implementation detail, and any
program relying on such details will be inherently non-portable.
Its surely not a "detail".
CJ said it was an IMPLEMENTATION detail.
If I have 100 million of those, the difference is a whooping
25 million!
If you have 100 million of those, you have a badly written algorithm
surely?
And I suspect if you get to the stage where you have enormous arrays of
large structures, you're probably running on a machine with sensible
amounts of memory eg 512GB anyway...
The fact that MANY (if not all) compilers give the programmer
a way to specify this is a testimnoy of the universal need
behind this.
My own experience is that packing is most needed at interfaces eg before
transmitting via a network or storing to disk. I've never to my
knowledge seen it used to save space.
P.S. It would be nice to avoid polemic... "Rubbish" means
here just that you do not agree with me I suppose
You're hardly innocent of this yourself....
REH wrote:
On Dec 5, 3:23 pm, REH <spamj...@stny.rr.comwrote:
>On Dec 5, 9:15 am, santosh <santosh....@gmail.comwrote:
>>James Kuyper wrote:
I suspect that it would be harder for the C standard to incorporate this
feature than for Ada, since the C standard attempts to be portable to a
wider range of machines than Ada. Also this might go against C's spirit
of being as efficient as possible and assuming that the programmer
knows what he is doing.
Why do you assume that C attempts to be "more portable" than Ada.
What are you basing your assertion on? What you do portably in C than
cannot be done in Ada?
REH
Oops, sorry. My poor editing made the above appear as if I am quote
James Kuyper. I apologize James.
No problem. I know how to interpret the indentation levels, so I was
only confused for a few moments; I assume most people will figure it out.
in comp.lang.c i read:
>Unaligned accesses to objects, should be banned. It has nothing to do
with portable C code, it might trigger a core dump on non-x86 CPU.
even on x86 systems with the right option enabled.
but i think jacob's point is that people want these "dense" struct's and
that there should be a way to get the compiler to emit the code necessary
to marshall the data. some systems would turn off or on some option while
the program is running, other systems would need the type of handling often
seen in c code for marshalling "plain" structs into and out of arrays of
unsigned char, etc...
--
a signature
those who know me have no need of my name wrote:
>
>Unaligned accesses to objects, should be banned. It has nothing
to do with portable C code, it might trigger a core dump on
non-x86 CPU.
even on x86 systems with the right option enabled.
but i think jacob's point is that people want these "dense"
struct's and that there should be a way to get the compiler to
emit the code necessary to marshall the data. some systems
would turn off or on some option while the program is running,
other systems would need the type of handling often seen in c
code for marshalling "plain" structs into and out of arrays of
unsigned char, etc...
This is opinion, but I think he, and they, are mistaken. Code has
quite different objectives today than it used to. There was a time
when memory was extremely precious, and we took almost all options
to economize it. Today, memory (and disk storage) is cheap, and we
use it freely. However nothing has reduced the need for clear and
understandable code.
BTW, please do not strip attributions for material you quote.
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
those who know me have no need of my name wrote:
in comp.lang.c i read:
>Unaligned accesses to objects, should be banned. It has nothing to do
with portable C code, it might trigger a core dump on non-x86 CPU.
even on x86 systems with the right option enabled.
but i think jacob's point is that people want these "dense" struct's and
that there should be a way to get the compiler to emit the code necessary
to marshall the data. some systems would turn off or on some option while
the program is running, other systems would need the type of handling often
seen in c code for marshalling "plain" structs into and out of arrays of
unsigned char, etc...
Well, I usually assume that compiler writers/maintainers know far more C
than myself, but there has been some counter-examples by one person.
OP's lack of attention to detail is striking, instead of
"most compilers provide some way to do this"
it should have been
"common compiler extension ..."
And when OP say:
"Note that under windows you must know this kind of stuff since windows
uses packed structures extensively."
I'm rather sure, he was ignorant to the fact that Windows may crash, when
#pragma pack (1)
is used, which is nothing less than shocking, when coming from someone
specializing on C compiler for this platform.
--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>
Tor Rustad wrote:
<snip>
And when OP say:
"Note that under windows you must know this kind of stuff since
windows uses packed structures extensively."
I'm rather sure, he was ignorant to the fact that Windows may crash,
when
#pragma pack (1)
is used, [ ... ]
Windows or the offending program?
in comp.lang.c i read:
>those who know me have no need of my name wrote:
>>Unaligned accesses to objects, should be banned. It has nothing
to do with portable C code,
>i think jacob's point is that people want these "dense" struct's and
that there should be a way to get the compiler to emit the code
necessary to marshall the data.
>I think he, and they, are mistaken. Code has quite different objectives
today than it used to. There was a time when memory was extremely
precious, and we took almost all options to economize it. Today, memory
(and disk storage) is cheap, and we use it freely. However nothing has
reduced the need for clear and understandable code.
c is still quite heavily used on platforms where memory remains tight,
though generally not quite so much as was once the case. still, if the
language (and thus this is really a comp.std.c issue more than clc)
provided a portable way of specifying that the struct should be as compact
as possible and that the platform demands for alignment be handled by the
compiler would mean even more code that would be portable, whether compiled
on a system with tight memory requirements or one with all the memory in
the world at hand. in the absence of such a facility we are left with
myriad implementation specific ways of accomplishing the same thing, and
(perhaps) fall-back code that handles it in the most general way possible
(it is hoped). much the same rationale applies as for the potentially
better code provided by memset or memcpy, else we should avoid them and
just write the loops.
>BTW, please do not strip attributions for material you quote.
i stripped none. i added what i felt was appropriate -- as i feel i am not
speaking to a person as much as on a topic, already described in the
subject, and so where the content originated is the next most important.
even that isn't really worth mention, though even more stiff necked
responses would arrive had i provided nothing. i note that you stripped
what i provided, surely you should walk your own walk, neh? oh, and that
double sig ... never mind, i know how to ignore/trim such things without
whining at the author about minor infelicities.
--
a signature
Tor Rustad wrote:
Well, I usually assume that compiler writers/maintainers know far more C
than myself, but there has been some counter-examples by one person.
OP's lack of attention to detail is striking, instead of
"most compilers provide some way to do this"
it should have been
"common compiler extension ..."
Yeah, that is SO COMPLETELY different...
>
And when OP say:
"Note that under windows you must know this kind of stuff since windows
uses packed structures extensively."
I'm rather sure, he was ignorant to the fact that Windows may crash, when
#pragma pack (1)
is used, which is nothing less than shocking, when coming from someone
specializing on C compiler for this platform.
You are just talking nonsense...
1) Windows will not crash. Your program will
2) "You are rather sure I am ignorant of the fact..."
I am rather sure you are speculating about things you do
not know. Everywhere in the windows headers you will
find #pragma pack(1) or pragma pag(8) or some other
value.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia wrote:
Tor Rustad wrote:
[...]
>And when OP say:
"Note that under windows you must know this kind of stuff since
windows uses packed structures extensively."
I'm rather sure, he was ignorant to the fact that Windows may crash, when
#pragma pack (1)
is used, which is nothing less than shocking, when coming from someone
specializing on C compiler for this platform.
You are just talking nonsense...
I was right then, you don't have a clue.
1) Windows will not crash. Your program will
There don't have to be a difference.
2) "You are rather sure I am ignorant of the fact..."
I am rather sure you are speculating about things you do
not know. Everywhere in the windows headers you will
find #pragma pack(1) or pragma pag(8) or some other
value.
Why the heck, do you need some userland header file to hide behind?
As a compiler maintainer/writer, you should be the expert!
--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>
santosh wrote:
Tor Rustad wrote:
<snip>
>And when OP say:
"Note that under windows you must know this kind of stuff since
windows uses packed structures extensively."
I'm rather sure, he was ignorant to the fact that Windows may crash,
when
#pragma pack (1)
is used, [ ... ]
Windows or the offending program?
or both
--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>
Tor Rustad wrote:
>
jacob navia wrote:
Tor Rustad wrote:
[...]
2) "You are rather sure I am ignorant of the fact..."
I am rather sure you are speculating about things you do
not know. Everywhere in the windows headers you will
find #pragma pack(1) or pragma pag(8) or some other
value.
Why the heck, do you need some userland header file to hide behind?
As a compiler maintainer/writer, you should be the expert!
I'm not sure what you're saying here. Are you saying that the
compiler should have built-in hard-coded knowledge of all of the
Windows API structs and their packing needs, rather than having
"some userland header file" define them?
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Kenneth Brody wrote:
Tor Rustad wrote:
>jacob navia wrote:
>>Tor Rustad wrote:
[...]
>>2) "You are rather sure I am ignorant of the fact..."
I am rather sure you are speculating about things you do
not know. Everywhere in the windows headers you will
find #pragma pack(1) or pragma pag(8) or some other
value.
Why the heck, do you need some userland header file to hide behind?
As a compiler maintainer/writer, you should be the expert!
I'm not sure what you're saying here. Are you saying that the
compiler should have built-in hard-coded knowledge of all of the
Windows API structs and their packing needs, rather than having
"some userland header file" define them?
No, I was saying that Jacob shouldn't argue his case, with what someone
else have done in their header files. His mistake is bad, since he is
supposed to be an expert, AFAIK a C compiler writer/maintainer,
particularly targeting Windows.
Like I have stated elsewhere, alignment faults will typically be fixed
(at a cost) by the kernel on Windows/x86, but not so, on Windows/MIPS or
Windows/x64.
The latter case is rather *important*, and people should very much
expect that a program executing in ring 0 (with misalignment bugs), will
crash the OS, while a programs in ring 3 crash themselves.
--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>
Tor Rustad <to********@hotmail.comwrites:
Like I have stated elsewhere, alignment faults will typically be fixed
(at a cost) by the kernel on Windows/x86, but not so, on Windows/MIPS
or Windows/x64.
This is a strange statement. On x86 and x86-64, the CPU does not
raise a fault at all for most kinds of misaligned arguments, in
the operating mode usually used, typically at minimal cost. And
modern versions of Windows do not run on MIPS, except for Windows
CE (which is not usually just called "Windows").
--
Ben Pfaff http://benpfaff.org
Ben Pfaff wrote:
Tor Rustad <to********@hotmail.comwrites:
>Like I have stated elsewhere, alignment faults will typically be fixed
(at a cost) by the kernel on Windows/x86, but not so, on Windows/MIPS
or Windows/x64.
This is a strange statement. On x86 and x86-64, the CPU does not
raise a fault at all for most kinds of misaligned arguments, in
the operating mode usually used, typically at minimal cost. And
modern versions of Windows do not run on MIPS, except for Windows
CE (which is not usually just called "Windows").
Not so strange, if you consider the Windows DDK doc:
"On 32-bit Windows platforms, the operating system automatically fixes
kernel-mode memory alignment faults and makes them invisible to the
application. It does this for the calling process and any descendant
processes. This feature, which often dramatically reduces performance,
has not been implemented in 64-bit Windows. Thus, if your 32-bit driver
contains misalignment bugs, you will need to fix them when porting to
64-bit Windows."
- Microsoft, Kernel-Mode Driver Architecture: Windows DDK
IIRC, regarding MIPS, I have already given reference to the MSDN doc
elsewhere in this thread. <g>
--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>
jacob navia <ja***@nospam.comwrites:
[...]
Under linux, that is another thing. printf for instance, expects
16 byte boundary aligned floating point data and will happily
crash if that is not the case.
<OT>
That appears not to be the case.
On a Linux x86 system, all three floating-point types have 4-byte
alignment; on a Linux x86-64 system, types float, double, and long
double have 4-, 8- and 16-byte size and alignment, respectively. But
on both systems, a floating-point object that's at an odd address can
be successfully printed.
</OT>
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Tor Rustad wrote:
>
Well, I find your statement stranger. :) Both IA-64 and AMD64, can be
controlled by a kernel to raise exceptions on alignment bugs. When
Microsoft state that this is what Windows might be doing, I see no
reason to believe otherwise.
You are right, but if you do not want problems, just do not use
those instructions that provoke alignment faults...
Always a source of trouble.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Tor Rustad <to********@hotmail.comwrites:
Ben Pfaff wrote:
>Tor Rustad <to********@hotmail.comwrites:
>>Ben Pfaff wrote:
Tor Rustad <to********@hotmail.comwrites:
Like I have stated elsewhere, alignment faults will typically be fixed
(at a cost) by the kernel on Windows/x86, but not so, on Windows/MIPS
or Windows/x64.
This is a strange statement. On x86 and x86-64, the CPU does not
raise a fault at all for most kinds of misaligned arguments, in
the operating mode usually used, typically at minimal cost. And
modern versions of Windows do not run on MIPS, except for Windows
CE (which is not usually just called "Windows").
Not so strange, if you consider the Windows DDK doc:
"On 32-bit Windows platforms, the operating system automatically fixes
kernel-mode memory alignment faults and makes them invisible to the
application. [...]
Then it's Microsoft who is making the strange statement.
Well, I find your statement stranger. :) Both IA-64 and AMD64, can be
controlled by a kernel to raise exceptions on alignment bugs. When
Microsoft state that this is what Windows might be doing, I see no
reason to believe otherwise.
We are not talking about Itanium, only about x86, MIPS, and x64.
Regardning AMD, the "AMD64 Architecture Programmerâÿôÿý™s Manual Volume
2: System Programming. Pub. #24593":
"Alignment Mask (AM) Bit. Bit 18. Software enables automatic alignment
checking by setting the AM bit to 1 when eFLAGS.AC=1. Alignment
checking can be disabled by clearing either AM or eFLAGS.AC to 0. When
automatic alignment checking is enabled and CPL=3, a memory reference
to an unaligned operand causes an alignment-check exception (#AC)."
Kernel mode, which is what we are talking about, runs with CPL=0,
and thus this bit has no effect in kernel mode. Furthermore,
this is not the operating mode usually used (as I qualified
earlier).
Because this is severely off-topic and, if anything, becoming
more so, I am going to make this my last post in this thread.
--
Peter Seebach on C99:
"[F]or the most part, features were added, not removed. This sounds
great until you try to carry a full-sized printout of the standard
around for a day."
Ben Pfaff wrote:
[..]
We are not talking about Itanium, only about x86, MIPS, and x64.
I was talking about Itanium all along, and believe, so was Microsoft.
--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>
Tor Rustad wrote:
Ben Pfaff wrote:
>Tor Rustad <to********@hotmail.comwrites:
>>Like I have stated elsewhere, alignment faults will typically be fixed
(at a cost) by the kernel on Windows/x86, but not so, on Windows/MIPS
or Windows/x64.
This is a strange statement. On x86 and x86-64, the CPU does not
raise a fault at all for most kinds of misaligned arguments, in
the operating mode usually used, typically at minimal cost. And
modern versions of Windows do not run on MIPS, except for Windows
CE (which is not usually just called "Windows").
Not so strange, if you consider the Windows DDK doc:
"On 32-bit Windows platforms, the operating system automatically fixes
kernel-mode memory alignment faults and makes them invisible to the
application. It does this for the calling process and any descendant
processes. This feature, which often dramatically reduces performance,
has not been implemented in 64-bit Windows. Thus, if your 32-bit driver
contains misalignment bugs, you will need to fix them when porting to
64-bit Windows."
- Microsoft, Kernel-Mode Driver Architecture: Windows DDK
IIRC, regarding MIPS, I have already given reference to the MSDN doc
elsewhere in this thread. <g>
The term "64-bit Windows" in such docs usually refers to Windows for the
Itanium Processor Family. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: John |
last post by:
Hi all,
Can a linked list be a member of a structure?
If so, when I add or remove an element from the linked list, the size
of the structure will change. Will it cause any problem?
Thanks a...
|
by: Amarendra |
last post by:
Folks,
This structure padding issue is bothering me now, could
not locate a satisfactory answer on clc, so here it goes...
I have a structure, given below:
typedef struct {
int flag;
char...
|
by: marco_segurini |
last post by:
Hi,
From my VB program I call a C++ function that gets a structure pointer
like parameter. The structure has a field that contains the structure
length and other fields.
My problem is that...
|
by: Laurent |
last post by:
Hello,
This is probably a dumb question, but I just would like to understand
how the C# compiler computes the size of the managed structure or classes.
I'm working on this class:
public...
|
by: Kislay |
last post by:
case 1 :
struct s
{
char c1; // 8
double d; // 8
int i1; // 4
char c2; // 4
int i2; // 4
};
|
by: =?Utf-8?B?QXlrdXQgRXJnaW4=?= |
last post by:
Hi Willy,
Thank you very much for your work.
C++ code doesnot make any serialization.
So at runtime C# code gives an serialization error at
"msg_file_s sa = (msg_file_s) bf.Deserialize(ms);"...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
