Turns out 8086 lets you do a far call to SS:BP, but not to SS:SP.

[riley@toot.cat]

Turns out 8086 lets you do a far call to SS:BP, but not to SS:SP. Hmm.

#push_your_code_to_stack_and_call_it

[uilebheist@polyglot.city]

@riley Ah but you see, doing a far call to SS:SP first pushes the return address and adjusts SP, then jumps to SS:SP, so it would try to execute its return address.
Which may be a great obfuscation tool, so it should be allowed.

[riley@toot.cat]

@Uilebheist FWIW, as far as I can see, about the most compact way one can implement a generic wrapper to a bunch of procedures on 8086 involves just putting a call wrapper instruction before the wrapped procedures, and having the wrapper start its work by pulling from its stack the "return address", which is actually the wrapped procedure. The call passes the code pointer free of charge this way, and the wrapper can retrieve it via a pop instruction which is just one byte long, or if the stars are just right, maybe even by actually ret:urning into the wrapped procedure (possibly by smuggling its own return address under that in the stack).

Unfortunately, at least on the original 8086, it's significantly slower than the two-instruction version:

• mov suitable_register, wrapped_procedure
• jmp wrapper.

The speed penalty should be diminished on later versions, especially from 486 onwards when on-chip cache became a thing, but I don't have detailed speed data on these at hand, just the original 8086 clock counts. Instruction clock counts went kind of haywire after 386, especially by about the Pentium's time, and started to depend on a lot of weird things, and often vary between x86 CPUs made by different manufacturers.