Page 1 of 1

[SOLVED]Assembly memory tester

Posted: Sat Feb 05, 2011 8:20 pm
by guilherme
An simple question:
The best way to test base memory on a 16-bit real-mode system is moving values into the bytes and then testing it?
like:
mov [bx],01h
Cmp [bx],01h
Jne MEMORYERROR
Obs.: this is just a example, the code i use is very more complex.

Re: Assembly memory tester

Posted: Sat Feb 05, 2011 9:29 pm
by Brendan
Hi,
guilherme wrote:An simple question:
The best way to test base memory on a 16-bit real-mode system is moving values into the bytes and then testing it?
You have to make sure you're not just testing cache. There's several methods of doing that:
  • Disable caches: This is the most obvious solution, and is easy to do (e.g. use the CD flag in CR0, on 80386 or later CPUs). It's also going to cripple performance so badly that you'll wish I didn't mention it.
    CLFLUSH: CLFLUSH isn't supported on older CPUs (it was first introduced in Pentium 4), so you probably won't want to use it. If you do want to use it it can improve performance (in theory, compared to WBINVD) by preventing the code you're executing from also being flushed from cache. It's probably best used in conjunction with SSE (and prefetch).
    WBINVD: WBINVD is supported on 80486 and later CPUs. It is very expensive, so you don't want to use it often. This means the best way would be to fill all memory with some sort of pattern, then do WBINVD once, then test all memory to see if the pattern is present and correct.
    Very Old CPUs: For 80386 and older CPUs there are no internal caches, but you still need to worry about external caches. There's also no way to explicitly flush the external caches (like WBINVD is meant to), and disabling caches (CD flag in CR0) sucks and doesn't work on extremely old CPUs. The best way to do it is to rely on the "least recently used" cache eviction - fill all memory with some sort of pattern and make sure it's too much data to fit in any external caches then test all memory to see if the pattern is present (so that any data you write has become "least recently used" and evicted from the cache before you read it).
Also, even without the cache issues, testing memory properly isn't easy. For a good description of the problems, see this article about memory testing. The end result is that you need to do a series of carefully selected tests, not just one test, and even the best thought-out series of tests may need to be run many many times (e.g. for several hours) before an intermittent fault is detected.


Cheers,

Brendan

Re: Assembly memory tester

Posted: Sat Feb 05, 2011 9:55 pm
by guilherme
Ok, now i understood.
Before i used a loop of 16777216 tests to each byte of the memory, by
moving it to an A value, compare to an A value, if not equal go to an error routine, to the same with an B and C values, and increasing A, if A got equal to the original byte value, increase B, and if B got equal to the original value increase C, and if C is equal too, restore that byte and proceed to the next one, so there are 166777216 loops (255*255*255).
Now i see that instead testing each byte 16777216 times, i'll have to do the same operation before with All bytes at once, like: moving All bytes to an A value, compare All them to A value, if not equal...
just an ask: how i set this topic as solved?

Re: Assembly memory tester

Posted: Sun Feb 06, 2011 7:44 am
by LloydAX86
Perhaps it would be useful to read the code they use in memtest86 and memtest86+ ?

http://en.wikipedia.org/wiki/Memtest86

:)