Prev: Communicating with SDBus.sys
Next: testcap ddk sample question.
From: heinz on 23 Feb 2006 00:44
> I didn't know how to instruct BUILD utility to link this obj file

PRECOMPILED_OBJ=test.obj

> .model SMALL, C

It's been a while since I've written masm files, but that's what you
used to use for 16-bit Dos. Don't you want ".model FLAT" here? I also
think it is good practice to set the calling convention using command
line options (/Gd for C) just like we do with the c compiler. We don't
put pragma's in each C file saying what calling convention is used; do
the same with your asm files. If you require a certain calling
convention, specify it on the appropriate PROC, just like we do with C
language.

From: Skywing on 23 Feb 2006 01:05
You can use the new __readmsr() intrinsic to do this without separate
assembler code.

"Sathyanarayanan" <Sathyanarayanan(a)discussions.microsoft.com> wrote in
message news:2DB74D8A-3A37-40C7-AF97-869F22F37B4F(a)microsoft.com...
>I needed to read few MSRs of CPU, for which I had to use assembly code.
>
> ----- contents of assembly.asm ------
> .model SMALL, C
> .686P
> .code
> ReadCPUMsr PROC PUBLIC MsrAddr:DWORD
> push ecx
> mov ecx, MsrAddr
> rdmsr
> pop ecx
> ret
> ReadCPUMsr ENDP
> End
> ----- contents assembly ends --------
>
> 1. When i compile this .asm file separately in makefile.inc (ml /c /Cx
> /coff
> /Fo$(O)\assembly.obj assembly.asm) it generates .obj, but I didn't know
> how
> to instruct BUILD utility to link this obj file along with my driver
> code -
> any inputs?
> 2. Alternately, I tried to include this .asm file name under SOURCES macro
> in sources file, but NMAKE returns error "NMAKE : fatal error U1073: don't
> know how to make 'objchk_wnet_x86\i386\assembly.obj'
>
> How do I successfully link my driver code with this assembly?
> --
> ++Sathya
>
>
> "Skywing" wrote:
>
>> You can put your assembler in a separate raw assembler module and link
>> the
>> resultant object file in. There are also a great many new intrinsics
>> supported by the x64 compiler (e.g. _writecr0) to do some things you used
>> to
>> need inline asm for.
>>
>> (Certainly, you should avoid assembler in NT drivers where possible - but
>> there are a couple of legitimate scenarios where it is necessary.)
>>
>> "Maxim S. Shatskih" <maxim(a)storagecraft.com> wrote in message
>> news:OaIxw1kNGHA.720(a)TK2MSFTNGP14.phx.gbl...
>> > You cannot use any assembler instructions on X64.
>> >
>> > --
>> > Maxim Shatskih, Windows DDK MVP
>> > StorageCraft Corporation
>> > maxim(a)storagecraft.com
>> > http://www.storagecraft.com
>> >
>> > "Sathyanarayanan" <Sathyanarayanan(a)discussions.microsoft.com> wrote in
>> > message
>> > news:E114DFE3-EA38-4421-812F-B451C3068C01(a)microsoft.com...
>> >> I badly need to use some assembly instructions in my driver &
>> >> application.
>> >> Compiling these codes with _asm keyword works fine for x86, but throws
>> >> error
>> >> for x64 & IA64. Then I learnt that _asm is not supported keyword for
>> >> these 2
>> >> architectures. How else can I call assembly instructions that can work
>> >> for
>> >> these architectures???
>> >> --
>> >> ++Sathya
>> >
>>
>>
>>


From: Sathyanarayanan on 23 Feb 2006 03:22
Folks,
1. I couldn't find __readmsr() declaration anywhere in DDK headers (I am
using Win 2003 SP1 DDK). Which header & library have this intrinsic?
2. I also tried specifying PRECOMPILED_OBJ build macro for assembly code obj
file, but still linker cribs unresolved external symbol for this PROC....The
log generated by build.exe does NOT contain this obj in list of linking. Also
looks like this build macro is needed for overriding default pre-compiled obj
file - is it right to use?
3. Also do we have __writemsr() too??
--
++Sathya


"Skywing" wrote:

> You can use the new __readmsr() intrinsic to do this without separate
> assembler code.
>
> "Sathyanarayanan" <Sathyanarayanan(a)discussions.microsoft.com> wrote in
> message news:2DB74D8A-3A37-40C7-AF97-869F22F37B4F(a)microsoft.com...
> >I needed to read few MSRs of CPU, for which I had to use assembly code.
> >
> > ----- contents of assembly.asm ------
> > .model SMALL, C
> > .686P
> > .code
> > ReadCPUMsr PROC PUBLIC MsrAddr:DWORD
> > push ecx
> > mov ecx, MsrAddr
> > rdmsr
> > pop ecx
> > ret
> > ReadCPUMsr ENDP
> > End
> > ----- contents assembly ends --------
> >
> > 1. When i compile this .asm file separately in makefile.inc (ml /c /Cx
> > /coff
> > /Fo$(O)\assembly.obj assembly.asm) it generates .obj, but I didn't know
> > how
> > to instruct BUILD utility to link this obj file along with my driver
> > code -
> > any inputs?
> > 2. Alternately, I tried to include this .asm file name under SOURCES macro
> > in sources file, but NMAKE returns error "NMAKE : fatal error U1073: don't
> > know how to make 'objchk_wnet_x86\i386\assembly.obj'
> >
> > How do I successfully link my driver code with this assembly?
> > --
> > ++Sathya
> >
> >
> > "Skywing" wrote:
> >
> >> You can put your assembler in a separate raw assembler module and link
> >> the
> >> resultant object file in. There are also a great many new intrinsics
> >> supported by the x64 compiler (e.g. _writecr0) to do some things you used
> >> to
> >> need inline asm for.
> >>
> >> (Certainly, you should avoid assembler in NT drivers where possible - but
> >> there are a couple of legitimate scenarios where it is necessary.)
> >>
> >> "Maxim S. Shatskih" <maxim(a)storagecraft.com> wrote in message
> >> news:OaIxw1kNGHA.720(a)TK2MSFTNGP14.phx.gbl...
> >> > You cannot use any assembler instructions on X64.
> >> >
> >> > --
> >> > Maxim Shatskih, Windows DDK MVP
> >> > StorageCraft Corporation
> >> > maxim(a)storagecraft.com
> >> > http://www.storagecraft.com
> >> >
> >> > "Sathyanarayanan" <Sathyanarayanan(a)discussions.microsoft.com> wrote in
> >> > message
> >> > news:E114DFE3-EA38-4421-812F-B451C3068C01(a)microsoft.com...
> >> >> I badly need to use some assembly instructions in my driver &
> >> >> application.
> >> >> Compiling these codes with _asm keyword works fine for x86, but throws
> >> >> error
> >> >> for x64 & IA64. Then I learnt that _asm is not supported keyword for
> >> >> these 2
> >> >> architectures. How else can I call assembly instructions that can work
> >> >> for
> >> >> these architectures???
> >> >> --
> >> >> ++Sathya
> >> >
> >>
> >>
> >>
>
>
>
From: heinz on 23 Feb 2006 22:19
If the intrinsics are there, that's by far the way to go. I'm not
familiar with them, but I do see a ReadMsr and WriteMsr function in
wdbgexts.h. Back to the code, two likely reasons you get an unresolved
external is either a calling convention mismatch or the proc is in the
wrong segment. Oh, and no reason to push & pop ecx as this register
does not need preserved across calls. If you do want to preserve an
arbitrary register, it is preferable to put USES ECX for example on
your proc statement.

From: Skywing on 23 Feb 2006 22:23
These might only be available with the x64 compiler in the DDK - it's new to
CL 14, and the x86 DDK compiler is still CL 13 as I recall.

"heinz" <heinz_baer(a)my-deja.com> wrote in message
news:1140751144.574035.320620(a)j33g2000cwa.googlegroups.com...
> If the intrinsics are there, that's by far the way to go. I'm not
> familiar with them, but I do see a ReadMsr and WriteMsr function in
> wdbgexts.h. Back to the code, two likely reasons you get an unresolved
> external is either a calling convention mismatch or the proc is in the
> wrong segment. Oh, and no reason to push & pop ecx as this register
> does not need preserved across calls. If you do want to preserve an
> arbitrary register, it is preferable to put USES ECX for example on
> your proc statement.
>


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Communicating with SDBus.sys
Next: testcap ddk sample question.