You can use the following to functions to store and load register
values:
// mov [ebx + offset], eax
X86EmitIndexRegStore(kEBX, offset, kEAX);
// mov eax,[ebx + offset]
X86EmitIndexRegLoad(kEAX, kEBX, offset);
In general you can always generate an array of bytes containing x86
instructions you need:
// mov [esp+8], ecx
static const BYTE replaceArg1[] = { 0x89, 0x4C, 0x24, 0x08 };
psl->EmitBytes(replaceArg1, sizeof(replaceArg1));
Vladimir
This posting is provided "AS IS" with no warranties, and confers no
rights.
-----Original Message-----
From: Discussion of the Rotor Shared Source CLI implementation
[mailto:[EMAIL PROTECTED] On Behalf Of Archana
Sent: Saturday, June 21, 2003 4:08 AM
To: [EMAIL PROTECTED]
Subject: [DOTNET-ROTOR] Coding mov mem <- reg using X86Emit..()
Hi,
Is there any way one can code mov register to memory location using
the set of Emit functions defined in i386/cgenx86.cpp?
the need arised because when i tried to write the ASM version of a piece
of code in i386/jitinterfacex86.cpp i needed quite a number of
temp-locations since all of them cannot fit into the available number of
registers. There are calls to stores in the code but they use
X86EmitIndexRegStore(..)
thanks & regards
archana
On Fri, 20 Jun 2003, Barry Bond wrote:
> You shouldn't have problems if you add additional thread
synchronization
> code. The suspend/resume code is reasonably robust - it suspends each
> thread, and if the thread is not executing managed code, it
immediately
> resumes it and lets the thread run until it re-enters managed code.
As
> long as you don't introduce new locks that need to be acquired by the
> actual suspend/resume code in the EE, you shouldn't see deadlocks.
>
> Be very careful adding new locks into the PAL - if you do, you'll need
> to update the critsec_count in order to avoid PAL-internal deadlocks.
>
> Barry
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
> -----Original Message-----
> From: Discussion of the Rotor Shared Source CLI implementation
> [mailto:[EMAIL PROTECTED] On Behalf Of Archana
> Sent: Friday, June 20, 2003 4:45 AM
> To: [EMAIL PROTECTED]
> Subject: [DOTNET-ROTOR] Using posix calls in rotor code
>
> Hi,
> Can we use Posix calls for thread synchronization in rotor code?
> because
> almost all calls used are the ones that are defined in /pal/unix
> directory. and crucial functions such as suspendEE, restartEE assume
> that
> all the threads are objects of 'class Thread'.
> to be more specific, if we introduce pthread mutexes/semaphores in
the
> code, what precautions should one take to ensure that the gc thread is
> successful in suspending all the threads?
>
> Thanks & regards
> archana
>
