Readit News logoReadit News
GuB-42 · 2 months ago
Hello sizecoders ;)

Additional resources:

http://www.sizecoding.org/wiki/DOS

A nice PDF with similar content:

https://pnx.tf/files/x86_opcode_structure_and_instruction_ov...

arjvik · 2 months ago
Is sizecoding the same as the demoscene?
mras0 · 2 months ago
Size optimizing assembly code finds use in a variety of places. Demoscene for size constrained things is one of them, but also "hacking"/exploits and of course "whitehat" stuff (patches / compiler optimization etc).
sagacity · 2 months ago
Relevant link to the current masters of the sizecoding niche: https://marqueedesign.demoscene.com/
classichasclass · 2 months ago
You could call it a sub-scene of the demoscene, I suppose.
Sharlin · 2 months ago
Need a couple of instructions for accessing memory (and possibly loading immediates) but otherwise seems like a perfectly adequate general-purpose instruction set. Might be fun (for some values of "fun") to write a compiler backend for it.
sparkie · 2 months ago
They're one byte opcodes, but not one byte ops. Most of them have operands which are encoded in a ModRM byte which follows the opcode. The ModRM may be followed by a SIB byte, and that may be followed by a a variable size immediate|displacement. There are also optional prefixes to the opcode.
jeffbee · 2 months ago
Tons of these have immediate operands. The question becomes is ADD with an implicit register destination and an immediate value in the next byte a "1-byte opcode"?
Sharlin · 2 months ago
Yes, indeed. I'd allow only mov to have a memory or immediate parameter as the only exception to one-byte encoding.
benlivengood · 2 months ago
Push, pop, inc, and dec with a 16-bit register argument are one byte, so is ret. That technically gives you enough to do anything, but you can include jz/jnz (which do take immediate bytes, maybe cheating?), stosw, lodsw, clc, and stc to implement Brainfuck (a little harder to perform input/output with single byte instructions, but maybe pretend the OS uses int1 or int3 for calls).
themafia · 2 months ago
You've always got the stack segment (SS) to play with and there's also:

https://www.felixcloutier.com/x86/xlat:xlatb

GeorgeTirebiter · 2 months ago
I don't understand, without further description of the symbols.
jcranmer · 2 months ago
The explanation of the symbols is largely found here: https://www.sandpile.org/x86/opc_enc.htm

Essentially, the uppercase letter of an operand is a combination of the operand type (immediate, register, memory) along with how that is encoded (as ModR/M bytes have a register and a register/memory field), while the lowercase letter is the size of the operand (largely 8-bit/16-bit/32-bit/64-bit for the 1-byte opcodes).

mras0 · 2 months ago
Not sure why you're being downvoted. You need a to know quite a bit of esoteric knowledge to parse this beyond knowing x86 opcodes (even x86 assembly).

It's more or less the same information you get from the intel manuals (specifically appendix 2A of https://www.intel.com/content/www/us/en/developer/articles/t...). There you can also see what e.g. "Jb" means (a byte sized immediate following the instruction that specifies a sign-extended relative offset to the instruction).

One-byte opcodes here differs from 2 byte opcodes (386+ IIRC) prefixed by a 0F byte and even more convoluted stuff added later.

charcircuit · 2 months ago
>Not sure why you're being downvoted.

I downvote people when they say they don't know what something is when they could have used a LLM to explain it to them.

Deleted Comment

ryanschneider · 2 months ago
A reverse engineer friend once taught me I could patch an x86 function with `0xEBFE` to get the CPU to spin forever. It wasn’t until much later that I understood that (IIRC) 0xEB is the “single byte” jump instruction and that of course 0xFE is -1 as a signed byte. Hence the spin.
hornd · 2 months ago
What does the 0eh comment mean?
rkagerer · 2 months ago
0eh? It's for Canadian segment addresses; pushes that CS register all the way home past the 49th parallel.