Re: after SIMD implementation, is it still a RISC?

Chris Gray wrote:
nmm1@xxxxxxxxxxxxx (Nick Maclaren) writes:

Dubiously. Having written those for a systems with and without it,
the extra difficulty is not significant.

Varying length ops can be a bit of nuisance when debugging, though. When
working with a program that has received an exception, I fairly often want
to see a handfull of instructions before the faulting one. If instructions
are fixed length, that is easy. If instructions are varying length, that
is harder. I usually don't want to disassemble the entire function - that
can yield hundreds of lines of output, and the stuff I want is somewhere
in the middle. Picking an address less than PC and starting there is error
prone, especially with x86's prefix bytes.

One solution would be for the debugger's disassembler to do the work for
me - start at the beginning of the function and silently parse instructions
until it gets to the one containing my given start address, then show me

Reverse engineering disassemblers, like the popular OllyDbg, seems to simply start at the closest known entrypoint, or it can disassemble the last 100 bytes or so. This is sufficient to regain sync for pretty much every single x86 program that hasn't been specially constructed to use only overlapping multi-byte opcodes.

those. Even that doesn't work if people are obfuscating code by putting
non-code in the middle of their functions, but since I'm generally debugging
my own code, that isn't an issue.

Using Olly (or other debuggers) to trace virus/worm code I've had to patch around code sequences designed to make debugging hard, like using the stack pointer (in 16-bit mode) as a general pointer register, decrypting code with no valid stack present.

Terje
--
- <Terje.Mathisen@xxxxxxxxxxxxx>
"almost all programming can be viewed as an exercise in caching"
.

Relevant Pages

  • Re: Code curosity
    ... The instructions the programmer writes are translated (for most ... > apps) into an unreadable but quite concise set of instructions the CPU ... Dedicated hackersdisassemble machine code in an effort to ... Others would do it to learn undocumented methods (like how does ...
    (comp.sys.mac.system)
  • Re: NDISASM: doesnt recognize all Mod/RM extension opcodes?
    ... If NASM supported all undocumented, all obsolete, or cpu specific ... instructions, it wouldn't be able to disassemble the ... You have SALC. ...
    (comp.lang.asm.x86)
  • Re: Lisp object code versus that of other languages
    ... > samples of Lisp object code (disassemble in sbcl) and found some pretty ... Since the SBCL code generator basically works by concatenating ... disassembly that shows which intermediate language instructions are ... producing the assembly instructions. ...
    (comp.lang.lisp)
  • Re: Table Driven Disassemblers are Slow?
    ... We will see yours the day you will do soemthing, ass-hole. ... Let's say it can disassembled 600,000 instructions in 1/10 ... disassemble each and every instruction more than 10 times? ... be outrageous and completely unnecessary (though a typical artifact of ...
    (alt.lang.asm)
  • Re: Mac Memory Models
    ... It would be nice, for instance, to have a 32bit process, but have access to all those new, many registers. ... x86-64 has 16GPRs (one of which is again a stack pointer I fear). ... IA64 is a different beast with totally different instructions. ...
    (comp.sys.mac.programmer.help)
Loading