[Mono-list] cpblk?
Dietmar Maurer
dietmar@ximian.com
24 May 2002 20:23:11 +0200
On Fri, 2002-05-24 at 19:18, Michael Giagnocavo wrote:
> >> Just assemble this -- it is a very simple case. It also
> >> demonstrates how the cpblk doesn't have to work when the src and dest
> >> addresses overlap. Test it on MSFT's CLR and you'll see that it
> >> eventually fails (and sometimes works). It'd be cool if Mono's
> always
> >> worked (even though Partition III specifies "unspecified" behaviour
> if
> >> src and dest overlap).
>
> > I just implemented it using unix memcpy(). Doku for memcpy states it
> > does not work for overlapping regions, but IMO it makes no sense to
> make
> > that work, it only makes things slower.
>
> Hmm. What if I want to move a block up by a few bytes?
Dick convinced me to use memmove which works with overlapping regions.
(until someone can prove that it is a performance problem).
>
> >> This is only a lame test, I'm working on a much longer test
> >> that's more accurate (protects IP) -- if you like I can send that
> later.
>
> > I would like to have a test that fails if CPBLK does not work. Your
> test
> > even pass if i implement CPBLK as NOP!
>
> Well, not a NOP, since then the program would be invalid (throws me a
> System.InvalidProgramException, since NOP does not have the same
> signature.
I meant implementing it in the jit using a nop instruction - i does not
show an exception/error in that case, so i cant use it for regression
tests.
But you're right, I shouldn't have sent such bad code.
The code was good enough to implement the opcode :-)
>
> >> Is jmp implemented?
>
> > No, but I will implement it as soon as I get some code to test ;-)
>
> Here are you two simple working tests that will print PASS or FAIL.
> Which other opcodes need a test?
wow - thanks for those test. Take a look at mono/mono/jit.c to see whats
not implemented (mono_analyze_stack()). We need more regression tests
for all kinds of instructions, especially value types, pinvoke parameter
passing, exceptions (maybe with fault handlers), delegates, remoting,
...
- Dietmar