InterlockedExhangeAdd

NTDEV
21

Oh really now … I was always taught that to subtract you change the sign
and add. Infact … most of the CPU architectures I have dealt with never
had “SUB” … we always
changed the sign of the subtractor and added.

Has Math 101 changed THAT much!?!?!?

Gary G. Little

“Mark Lobo” wrote in message news:xxxxx@ntdev…
>
>
> Yeah, but NT doesnt have an InterlockedExchangeSub.
> Would the only difference be using a subl instead of
> xadd?
>
>
> — Nick Ryan wrote:
> > Ntddk.h has assembly implementations of all of these
> > functions defined
> > as inlines. I suppose you can borrow them. I don’t
> > see any reason why
> > they wouldn’t work on other x86 operating systems
> > as-is.
> >
> > - Nick Ryan
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On
> > Behalf Of Mark Lobo
> > > Sent: Sunday, June 15, 2003 6:51 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] InterlockedExhangeAdd
> > >
> > >
> > > Guys,
> > > Working on a Sunday evening and just need the
> > assembly
> > > implementation for InterlockedExchangeAdd and an
> > equivalent
> > > function for substraction. Just porting some stuff
> > and
> > > changing some at the same time, so need an OS
> > independent x86
> > > way of doing these things. Im no asembly expert,
> > so need some help.
> > >
> > > For InterlockedExchangeAdd I have:
> > > long InterlockedExchangeAdd(long * p_plValue, long
> > > p_lAdd)
> > > {
> > > long l_lResult;
> > > asm volatile (
> > > “push %%EBX;”
> > > “movl %1, %%EBX;”
> > > “movl %2, %%EAX;”
> > > “lock; xadd %%EAX, (%%EBX);”
> > > “inc %%EAX;”
> > > “mov %%EAX, %0;”
> > > “pop %%EBX”
> > > : “=g”(l_lResult) : “g”(p_plValue),
> > “g”(p_lAdd) );
> > > return l_lResult;
> > > }
> > >
> > > is that correct? Will it work on Linux correctly
> > as in
> > > it will add the new value and return the old
> > value?
> > >
> > > Also I need the substract equivalent of the above
> > in
> > > assembly, that will substract a value from the
> > > variable atomically and return the old value. Can
> > > someone please give me the asm source for that?
> > >
> > > Thanks in advance folks,
> > > Mark
> > >
> > >
> > > Do you Yahoo!?
> > > SBC Yahoo! DSL - Now only $29.95 per month!
> > http://sbc.yahoo.com
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as:
> > xxxxx@nryan.com
> > > To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as:
> > xxxxx@yahoo.com
> > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
>
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>
>
>

22

I’m not sure OSR is a good case, because I suspect your practices are
better than most. Can anyone else volunteer experiences in porting to
64-bit?

By the way, did you mean: “cuz there’s NO emulation or translation to
perform”?

–
If replying by e-mail, please remove “nospam.” from the address.

James Antognini

23

Geez, I was working on 64-bit drivers for NT back before 1999 at DEC. It
just happens that the vendors dropped support for the Alpha after that.

One basic rule is pretty simple: sizeo(long) != sizeof(char *).
Another thing to look out for is data alignment. Depending on processor
type, fetching or storing a data item from/to an address that’s not
naturally aligned for that datatype may cause an exception.

By the way, the _asm code posted earlier wouldn’t have worked on an Alpha
either :slight_smile:

“James Antognini” wrote in message
news:xxxxx@ntdev…
>
> I’m not sure OSR is a good case, because I suspect your practices are
> better than most. Can anyone else volunteer experiences in porting to
> 64-bit?
>
> By the way, did you mean: “cuz there’s NO emulation or translation to
> perform”?
>
> –
> If replying by e-mail, please remove “nospam.” from the address.
>
> James Antognini
>
>
>
>

24

xxxxx@sneakemail.com said:

I’m not sure OSR is a good case, because I suspect your practices are
better than most. Can anyone else volunteer experiences in porting to
64-bit?

Linux kernel and drivers have supported 64bit (alpha, sparc64, ppc64,
Itanium, AMD64) for eons. It’s not hard at all to write 64bit clean
driver code, especially if you are using READ_REGISTER_ULONG and friends
(readl et al under Linux) like you are supposed to. The only other issue
is to not cast pointers to int.

Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”