c++

NTDEV
81

+1 :wink:

I guess this list would be better place if *some* people learn this technique, too.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Martin O’Brien[SMTP:xxxxx@evitechnology.com]
Reply To: Windows System Software Devs Interest List
Sent: Monday, January 28, 2008 6:15 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] c++

I’m sort of glad to learn that I’m not the only person who does this,
perhaps not as often as I should.

mm
xxxxx@osr.com wrote:
> [quote]
> Can I recommend my practice of typing my inflamed response then deleting it before sending?
> [/quote]
>
> There is a lot to be said for this practice.
>
> I can honestly say that I delete more postings to this list than I send. By quite a large margin, in fact. This includes some really long, and even some technical, ones.
>
> Peter
> OSR
>
>

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

82

may I suggest a filter driver that plugs in to the filter manager FS upper
filter driver, that way you don’t take up another stack location :slight_smile:
do you need this to be transaction aware?

you may just want to let yourself be fired… finding a new job can be
easier than writing a good FS filter driver.

From: “Tim Roberts”
Sent: Monday, January 28, 2008 9:41 AM
To: “Windows System Software Devs Interest List”
Subject: Re: [ntdev] c++

> Dan Kyler wrote:
>> It depends on what you mean. I prefer to indent my code by pressing the
>> TAB
>> key, which causes my editor to insert space characters. It gets really
>> fun
>> when one developer’s editor is set to tabs and another’s is set to
>> spaces.
>>
>
> Please help me write a file system upper filter driver to change all the
> tabs to spaces in every file that I write. My boss says that’s the only
> way it can be done, so that’s what I need. Oh, and I have to have a
> solution by Friday, so a pointer to working and fully commented code is
> needed or else I will be fired.
>
> Thanks in advance!
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

83

> But that is only because you are used to the Intel/MASM syntax.

Well, what syntax are you supposed to get used to if you deal with *INTEL* processor, apart from Intel assembly???

Had you “grown up” using the AT&T syntax with many other processors,
there wouldn’t be anything annoying at all about it.

Well, if I was dealing with some other processor I would not find it annoying at all, no matter how
different its syntax is from the one I am accustomed to. However, when I deal with x86, I expect x86 syntax. To give you an idea, would you prefer to make your posts in English or in some “neutral” language like Esperanto???

Anton Bassov

84

A common practice I suspect. Often just typing up the rant is sufficient to help one relax.

And it’s a much less expensive practice than my old one of destroying keyboards in a “hulk smash” style fit of rage.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Monday, January 28, 2008 8:18 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] c++

There is a lot to be said for this practice.

I can honestly say that I delete more postings to this list than I send. By quite a large margin, in fact. This includes some really long, and even some technical, ones.

Peter
OSR

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

85

xxxxx@hotmail.com wrote:

> Had you “grown up” using the AT&T syntax with many other processors,
> there wouldn’t be anything annoying at all about it.
>

Well, if I was dealing with some other processor I would not find it annoying at all, no matter how
different its syntax is from the one I am accustomed to. However, when I deal with x86, I expect x86 syntax.

There is no such thing. Syntax is defined by the assembler, not by the
processor. NASM, FASM, MASM, A86, and others all use slightly different
syntax. Even the syntax used in Intel’s manuals does not match the
syntax MASM expects.

To give you an idea, would you prefer to make your posts in English or in some “neutral” language like Esperanto???

If I were writing posts on an Esperanto forum, I’d expect to have to
write in Esperanto in order to be understood. Similarly, if one is
writing assembly language for a Unix system, one should expect to use
the Unix assembler syntax. The processor is irrelevant in that discussion.

You are looking at this from the point of view of a weathered MASM
jockey suddenly being thrust into a Linux world. The much more common
case (until recently) was the point of view of the weathered Unix hacker
now trying to get his kernel stuff working on an x86 processor. That
hacker knows the AT&T syntax, and just needs to learn the x86 opcode names.

Linux has skewed this demographic, because its easy availability has
meant that huge swarms of DOS- and Windows-trained MASM programmers
started experimenting with Linux. The gcc folks had to capitulate by
introducing an “Intel syntax” option, which the gas assembler now
supports. You would find that syntax much more familiar.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

86

Indeed! In fact, as far as constructing a reasonably good assembler language, MASM sucks seriously. Almost as much as C++ sucks as a high level language, but not quite so much.

I remember Borland TASM, which had something called “ideal mode” – VERY much more consistent, less cryptic, and easier to read. Sadly, the operands still moved right to left, which IMHO is contrary to G-d’s intended design… which was of course, manifest in the perfection that is (was) PDP-11 assembler language.

Peter
OSR

87

>>However, when I deal with x86, I expect x86 syntax.

There is no such thing. Syntax is defined by the assembler, not by the processor. NASM, FASM, > MASM, A86, and others all use slightly different syntax. Even the syntax used in
Intel’s manuals does not match the syntax MASM expects.

I am afraid you are confusing assembly (i.e. bare-bone instruction set without any directives) and *MACRO* assembler. All above mentioned things are macro assemblers that are, indeed, slightly different from one another. However, all these assemblers are based upon Intel assembly, i.e. instruction set as it is described in Intel Manuals. In Intel assembly, first, destination and source operands come respectively first and second, and, second, the same instruction can be used regardless of operand size. However, GNU assembler goes further than just being different from other macro assembler - it turns the instruction set itself upside down

If I were writing posts on an Esperanto forum, I’d expect to have to write
in Esperanto in order to be understood.

Exactly. Similarly, if you want your *assembly* code to be understood, you may expect to write it in instruction set as it is defined by CPU manufacturer, rather than turning it upside down.

Similarly, if one is writing assembly language for a Unix system,
one should expect to use the Unix assembler syntax.

Again, this holds only for macro assembler (i.e. directives). However, I would expect the instruction set itself to match the one defined by the CPU manufacturer…

You are looking at this from the point of view of a weathered MASM jockey suddenly
being thrust into a Linux world. The much more common case (until recently)
was the point of view of the weathered Unix hacker now trying to get his kernel
stuff working on an x86 processor. That hacker knows the AT&T syntax, and just
needs to learn the x86 opcode names.

Despite highly provocative “C vs C++” name, this thread has not yet had a “flame war” that one would normally expect on it. The funniest thing here is that we are about to start a “flame war”
( which is hardly surprising for the thread with so provocative name) on a totally different topic that one would normally expect to see in a UNIX NG, rather than here - “AT&T syntax vs Intel syntax”…

Anton Bassov

88

> Well, what syntax are you supposed to get used to if you deal with *INTEL* ?

processor, apart from Intel assembly???

gas uses portable assembler syntax. I expect that you even can use %1 instead
of %eax there.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

89

> the operands still moved right to left, which IMHO is contrary to G-d’s intended design…

It was just made conform to Intel instruction set as it is described in Intel Manuals. GNU seems to be the first assembler that challenges this part…

Anton Bassov

90

> I am afraid you are confusing assembly (i.e. bare-bone instruction set

without >directives) and *MACRO* assembler.

No. These are not macros.

The assembly language features of:

  • lexical style of register names (prefixes etc)

  • lexical style of labels

  • lexical style of hardcoded numbers

  • lexical style of denoting the addressing operators ( or such)

  • order of operands

  • are not CPU-dependent. Yes, assembler is a CPU-dependent language, but the
    lexical issues above can be made portable, and this is what gas does.

The only nonportable things are opcode names, code generation sequence for each
opcode and the per-opcode operand requirements.

With such an approach, gas can easily be ported to generate the code for any
new CPU in the world.

I dunno on what CPU gas has originated, maybe on 680x0 family (as most GNU/UNIX
software), which is claimed to be the most direct successor of glorified PDP-11
line.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

91

> The only nonportable things are opcode names, code generation

sequence for each opcode and the per-opcode operand requirements.

Exactly. As long as your assembler for x86 conforms to “MOV r/m(size),r(size) - MOV r(size) , r/m(size) -etc” style as it is described in Intel Manuals, there is nothing wrong with it. However , when you start changing the order of operands and introduce your own instructions that don’t exists in x86 instruction set (i.e. MOVB, MOVS, MOVL and MOVQ “variations on the theme” of MOV), you already screw it up (at least in my understanding of things) , because you already don’t conform to the original instruction set…

Anton Bassov

92

Ah, macro-11. You could teach that assembler to do just about anything. I taught it to generate DG-Nova code 'cause, well, I was young, in a hurry, dumb, and didn’t have a nova assembler but was awash in PDP-11s. Now I have done my part to spiral this thread into oblivion and will now shut up.
-dave

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Monday, January 28, 2008 10:32 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] c++

Indeed! In fact, as far as constructing a reasonably good assembler language, MASM sucks seriously. Almost as much as C++ sucks as a high level language, but not quite so much.

I remember Borland TASM, which had something called “ideal mode” – VERY much more consistent, less cryptic, and easier to read. Sadly, the operands still moved right to left, which IMHO is contrary to G-d’s intended design… which was of course, manifest in the perfection that is (was) PDP-11 assembler language.

Peter
OSR

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

93

Can someone clarify? Is asm permitted in Kernel Mode? Thx, M

94

Permitted? Yes. Discouraged and a bad idea, except for certain very specific instances? Also yes.

Peter
OSR

95

Also, on x64, CL does not support inline assembler, if that’s what he’s
after.

mm

xxxxx@osr.com wrote:

Permitted? Yes. Discouraged and a bad idea, except for certain very specific instances? Also yes.

Peter
OSR

96

I think that it is necessary to build all drivers now for 64 bit as well as
32 bit OS, so does this mean excluding asm altogether? Or is there an
approved MASM or equivalent for kernel use? So far I have avoided using
assembler but I am now considering whether it is worth it to optimise some
core routines and/or to use the DSP type instructions available in the
latest CPUs. Thanks for any views… Sorry if this is off topic, but it has
been about assemblers for the last few days so got me thinking. Mike.

>>>>
From: Martin O’Brien
Newsgroups: ntdev
To: Windows System Software Devs Interest List
Sent: Tuesday, January 29, 2008 3:34 PM
Subject: Re:[ntdev] c++

Also, on x64, CL does not support inline assembler, if that’s what he’s
after.

mm

xxxxx@osr.com wrote:

Permitted? Yes. Discouraged and a bad idea, except for certain very
specific instances? Also yes.

Peter
OSR

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

97

Definitely on topic, and certainly more so than anything else in this
thread. You can use assembler in the kernel, but on x64 (using
Microsoft tools) you must compile assembler seperately, and can not use
inline assembler in C or C++. That is, assembler must be in it’s own
source file. The WDK comes with x86_32 and x86_64 (and Itanium,
perhaps) versions of ML (MASM). I don’t recall exactly how one does
this with BUILD, but I seem to recall something about placing the file
in an architecture subdirectory and adding to SOURCES, but that may not
be correct. Check the WDK documentation for this.

Good luck,

mm

Mike Kemp wrote:

I think that it is necessary to build all drivers now for 64 bit as well
as 32 bit OS, so does this mean excluding asm altogether? Or is there an
approved MASM or equivalent for kernel use? So far I have avoided using
assembler but I am now considering whether it is worth it to optimise
some core routines and/or to use the DSP type instructions available in
the latest CPUs. Thanks for any views… Sorry if this is off topic, but
it has been about assemblers for the last few days so got me thinking.
Mike.

>>>>>
From: Martin O’Brien
Newsgroups: ntdev
To: Windows System Software Devs Interest List
Sent: Tuesday, January 29, 2008 3:34 PM
Subject: Re:[ntdev] c++

Also, on x64, CL does not support inline assembler, if that’s what he’s
after.

mm

xxxxx@osr.com wrote:
> [quote]
> Is asm permitted in Kernel Mode?
> [/quote]
>
> Permitted? Yes. Discouraged and a bad idea, except for certain very
> specific instances? Also yes.
>
> Peter
> OSR
>
>

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

98

> does this mean excluding asm altogether?
No, only the inline one is out for 64 bit.
You still can have your *.asm compiled separately.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-313138-
xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Tuesday, January 29, 2008 11:15 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] c++

I think that it is necessary to build all drivers now for 64 bit as
well as
32 bit OS, so does this mean excluding asm altogether? Or is there an
approved MASM or equivalent for kernel use? So far I have avoided using
assembler but I am now considering whether it is worth it to optimise
some
core routines and/or to use the DSP type instructions available in the
latest CPUs. Thanks for any views… Sorry if this is off topic, but it
has
been about assemblers for the last few days so got me thinking. Mike.

>>>>>
From: Martin O’Brien
Newsgroups: ntdev
To: Windows System Software Devs Interest List
Sent: Tuesday, January 29, 2008 3:34 PM
Subject: Re:[ntdev] c++

Also, on x64, CL does not support inline assembler, if that’s what he’s
after.

mm

xxxxx@osr.com wrote:
> [quote]
> Is asm permitted in Kernel Mode?
> [/quote]
>
> Permitted? Yes. Discouraged and a bad idea, except for certain very
> specific instances? Also yes.
>
> Peter
> OSR
>
>

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

99

> 32 bit OS, so does this mean excluding asm altogether?

Only inline __asm in C/C++ code.

Or is there an
approved MASM or equivalent for kernel use?

Yes.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

100

Thanks, that’s very useful info. This is only at the “what if” stage at the
moment but a lot of what I do is speculate in what is possible for the next
bright idea (and if I’m unlucky, implementing it). I had misunderstood that
asm was out. Now I think it will be possible to create a BSOD faster than
ever before. M

>>>>>>>>
From: Martin O’Brien
Newsgroups: ntdev
To: Windows System Software Devs Interest List
Sent: Tuesday, January 29, 2008 4:33 PM
Subject: Re:[ntdev] c++

Definitely on topic, and certainly more so than anything else in this
thread. You can use assembler in the kernel, but on x64 (using
Microsoft tools) you must compile assembler seperately, and can not use
inline assembler in C or C++. That is, assembler must be in it’s own
source file. The WDK comes with x86_32 and x86_64 (and Itanium,
perhaps) versions of ML (MASM). I don’t recall exactly how one does
this with BUILD, but I seem to recall something about placing the file
in an architecture subdirectory and adding to SOURCES, but that may not
be correct. Check the WDK documentation for this.

Good luck,

mm

Mike Kemp wrote:

I think that it is necessary to build all drivers now for 64 bit as well
as 32 bit OS, so does this mean excluding asm altogether? Or is there an
approved MASM or equivalent for kernel use? So far I have avoided using
assembler but I am now considering whether it is worth it to optimise some
core routines and/or to use the DSP type instructions available in the
latest CPUs. Thanks for any views… Sorry if this is off topic, but it
has been about assemblers for the last few days so got me thinking. Mike.

>>>>>
From: Martin O’Brien
Newsgroups: ntdev
To: Windows System Software Devs Interest List
Sent: Tuesday, January 29, 2008 3:34 PM
Subject: Re:[ntdev] c++

Also, on x64, CL does not support inline assembler, if that’s what he’s
after.

mm

xxxxx@osr.com wrote:
> [quote]
> Is asm permitted in Kernel Mode?
> [/quote]
>
> Permitted? Yes. Discouraged and a bad idea, except for certain very
> specific instances? Also yes.
>
> Peter
> OSR
>
>

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer