From: heinz on
Now that you say that, I see the __readmsr and __writemsr intrinsics
documented in Visual Studio 2005 (CL 14 as you say) and they are
supported in both 32-bit and x64. The docs already state "This function
is only available in kernel mode" so looks like a sign of things to
come in a future DDK. Not everyone would agree with this, but what I
would do in this situation is build your driver with the visual studio
2005 compiler instead of the old one that comes with the DDK so you can
use the intrinsics versus writing an asm module that you'd probably
just throw away when the next DDK comes out. CL 14 is a better
optimizing compiler too. If you do stick with an asm file, you should
name your function __readmsr and match the prototype parms & return so
you can just drop the asm file in the future without any code changes
to your C files which would pick up the intrinsic.

From: Skywing on
I believe that you should be able to use these intrinsics with the current
x64 DDK compiler, just not the current x86 one.

"heinz" <heinz_baer(a)my-deja.com> wrote in message
news:1140756283.141790.12070(a)p10g2000cwp.googlegroups.com...
> Now that you say that, I see the __readmsr and __writemsr intrinsics
> documented in Visual Studio 2005 (CL 14 as you say) and they are
> supported in both 32-bit and x64. The docs already state "This function
> is only available in kernel mode" so looks like a sign of things to
> come in a future DDK. Not everyone would agree with this, but what I
> would do in this situation is build your driver with the visual studio
> 2005 compiler instead of the old one that comes with the DDK so you can
> use the intrinsics versus writing an asm module that you'd probably
> just throw away when the next DDK comes out. CL 14 is a better
> optimizing compiler too. If you do stick with an asm file, you should
> name your function __readmsr and match the prototype parms & return so
> you can just drop the asm file in the future without any code changes
> to your C files which would pick up the intrinsic.
>


From: heinz on
I verified this and you are correct. The x64 compiler in the DDK is CL
14 already, but the DDK does not have the prototype in its headers.
Just add the below prototype and it will inline the rdmsr instruction
when it sees you use it:

extern "C" unsigned __int64 __readmsr(int);

From: Tim Roberts on
Sathyanarayanan <Sathyanarayanan(a)discussions.microsoft.com> wrote:
>
>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?

Create a subdirectory called i386. Move your "assembly.asm" into the i386
subdirectory. Now, in your "sources", add:

I386_SOURCES = i386\assembly.asm

That's all it takes. Build will assemble and link it.

The same thing works with:

IA64_SOURCES = ia64\assembly.s

AMD64_SOURCES = amd64\assembly.asm
--
- Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: Sathyanarayanan on
Cool !!
I just used below declarations for x64 (kept same _asm code for x86) and it
successfully builds :-). I will test and update if it works/any issues, etc.
Thanks a lot folks!!

BTW, I am also gonna try I386_SOURCES macro addition and will let you know.

extern unsigned __int64 __readmsr(int);
extern void __writemsr(int,unsigned __int64);

(extern "C" - declaration throws compiler error).
--
++Sathya


"heinz" wrote:

> I verified this and you are correct. The x64 compiler in the DDK is CL
> 14 already, but the DDK does not have the prototype in its headers.
> Just add the below prototype and it will inline the rdmsr instruction
> when it sees you use it:
>
> extern "C" unsigned __int64 __readmsr(int);
>
>