Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.asm.x86    |    Ahh, the lost art of x86 assembly    |    4,675 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 2,869 of 4,675    |
|    James Harris to Terje Mathisen    |
|    Re: Look back to "just for the H@ck"    |
|    20 Jul 17 00:20:32    |
      From: james.harris.1@nospicedham.gmail.com              On 19/07/2017 21:25, Terje Mathisen wrote:       > James Harris wrote:       >> One more "wheel", though, just out of interest. I see that of the       >> opcodes available there are, in hex, these "ranges":       >>       >> the 3x range which gives some very useful xor and cmp the 7x range       >> which provides short jumps _if_ offsets fit       >       > Exactly right. :-)       >>       >> but there are not many useful instructions available. Has it already       >> been looked at to xor a run of bytes in order to make some other       >> opcode ranges available (and maybe make jCC offsets more amenable)?       >       > We use XOR in the SMC part to change known legal ascii values into the       > desired opcode bytes.       >       >> I've not worked out any particular xor value. Just asking if it's       >> already been considered.       >       > In my code I added one more (strong!) limitation: I wanted to write a       > primary decoder that would work with as little self-modification as       > possible, so when I figured out a way that only needed to fixup the       > absolute minimum (a single short (two-byte)) backwards branch       > instruction) I called it a day.              So the only thing you "self-modify" is a branch offset? That's       /definitely/ cool. I always hated self-modifying code. But branch       offsets have to be legit as it's very similar to doing the work of a       linker.              Interesting you mention imposing an additional limitation on yourself.       If I had a go at it I'd be itching to add some of my own. Things like              * A subsequent run from the start must also work.              * Need to cope with CR and LF at any point (after the first N bytes, for       some reasonable N).              * Only 8086 instructions.              * Not rely on [SP] being zero - in case of non-compliant environment. (I       haven't found the .COM spec but from what people have said I guess that       that 16-bit word is supposed to be zero ... perhaps so that a near       return gets to CS:0 which is termination code.)              Maybe others have done some of that. In any case, I am not volunteering       ... the challenge already looks more than hard enough. Now I know what       it was about I wish I'd followed from the beginning.                     --       James Harris              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca