I have a little library of lock-free data structures.
I’m porting the abstraction layer to the Windows kernel.
To my really quite considerable surprise, it appears to me now that
there is no support for atomic 64 bit add, no support for atomic 64-bit
compare-and-swap on x86 and no support for atomic 128 bit compare-and-
swap on x64/IA64 - all of which are supported in user-mode!
I also recall that the current MS compiler no longer permits in-line
assembly, so I believe I can’t even write assembly to use these
instructions.
Am I correct in my understanding?
Regarding the last, yes, inline assembler is not supported (by msft compilers, at least), but you can always use ML64 (part of WDK) to assemble separately and link the functions in.
mm
xxxxx@evitechnology.com wrote:
Regarding the last, yes, inline assembler is not supported (by msft
compilers, at least), but you can always use ML64 (part of WDK) to
assemble separately and link the functions in.
Yes - but as you know, that means learning how to do assembly. I want
to, but not on the critical path 
Anyway, the compiler instrincs sorted everything out.
I have now however spent half a day fighting the apparently moronic
kernel build system. I had hoped by now I could actually have source
files over multiple directories. Rather than mutiliate for all
platforms a sane directory structure, I’ve added a batch file, which
will mutiliate the directory structure only for those who are compiling
for Windows kernel. Poor fuckers.
My problem now is trying to get object files in a different directory to
the final binaries - and I do believe I cannot, at least not in any
straightforward way.
Oh - and trying to figure out what you have to tell build to make it
clean. I thought it was build /clean, but given the lack of cleaning, I
must be mistaken.
That is the way it is. There are restrictions on the placement of files and
this has been covered many times in the past. Doing the ‘clean’ is easy
with build using the -ceZ parameters. If you are not using build directly
or via a proxy such as ddkbuild.bat, then move your post to nttalk where we
can ignore it or flame it.
“Toby Douglass” wrote in message
news:xxxxx@ntdev…
> xxxxx@evitechnology.com wrote:
>> Regarding the last, yes, inline assembler is not supported (by msft
>> compilers, at least), but you can always use ML64 (part of WDK) to
>> assemble separately and link the functions in.
>
> Yes - but as you know, that means learning how to do assembly. I want
> to, but not on the critical path
>
> Anyway, the compiler instrincs sorted everything out.
>
> I have now however spent half a day fighting the apparently moronic
> kernel build system. I had hoped by now I could actually have source
> files over multiple directories. Rather than mutiliate for all
> platforms a sane directory structure, I’ve added a batch file, which
> will mutiliate the directory structure only for those who are compiling
> for Windows kernel. Poor fuckers.
>
> My problem now is trying to get object files in a different directory to
> the final binaries - and I do believe I cannot, at least not in any
> straightforward way.
>
> Oh - and trying to figure out what you have to tell build to make it
> clean. I thought it was build /clean, but given the lack of cleaning, I
> must be mistaken.
>
xxxxx@yoshimuni.com wrote:
“Toby Douglass” wrote in message
> news:xxxxx@ntdev…
> > Oh - and trying to figure out what you have to tell build to make it
> > clean. I thought it was build /clean, but given the lack of cleaning, I
> > must be mistaken.
> That is the way it is. There are restrictions on the placement of
> files and
> this has been covered many times in the past.
Oh I know - just…it’s been a couple of years since I looked at if the
DDK had improved building and you always hope.
> Doing the ‘clean’ is easy
> with build using the -ceZ parameters.
Yes - I ended up seeing I could do the clean using various specific
build parameters. Crazy. Actually, what annoys me is that /clean
exists when it doesn’t work. It’s misleading. Or does it work for
some people in some situations? but that’s misleading too.
> … apparently moronic kernel build system.
As David already pointed out, it is better to move this part to NTTALK, where one is free to discuss the above
(as well as a statement that would result if the last two words get removed from the above quotation) without annoying those who have no interest in discussions like that -for many (if not most) NTDEV readers this kind of discussion is nothing more than just annoying noise, so that it does not seem to make sense to pursue it here …
Anton Bassov