Around 1999, I was trying to make games in Borland Pascal. Copying the framebuffer in plain Pascal was too slow, so I needed handwritten assembly. The DB 66h trick was a game changer for me.
The Borland Pascal compiler I used produced 16-bit programs (anyone remember segment:offset memory addressing?), and its built-in assembler didn’t support 32-bit instructions. But a 386 or newer CPU could execute them even inside a 16-bit program. I could emit the operand-size override prefix with DB 66h. The CPU then interpreted the following 16-bit instruction as its 32-bit equivalent.
My LSGUNIT graphics library contains this in Move32:
MOV CX,count
MOV BL,CL
AND BL,3
SHR CX,2
DB 66h
REP MOVSW
MOV CL,BL
REP MOVSB
This excerpt starts after setting up the source and destination pointers. With 66h, MOVSW became MOVSD, copying four bytes per repetition instead of two. The count was divided by four, then MOVSB handled the remaining bytes. A 320×200 framebuffer took 16,000 repetitions to copy its 64,000 bytes. Addressing still stayed 16-bit.
The Triangle routine used the same approach for fixed-point calculations:
db $66, $0f, $bf, $46, offset x1 { movsx eax,[x1] }
db $66; sal ax,16
The first line sign-extended a coordinate into EAX; the second shifted it left by 16 bits. Another prefixed instruction, REP STOSW, filled four pixels at a time. These were the parts where plain Pascal couldn’t give me the speed I needed.
I imagined the serious developers were using C++ and DJGPP, with a proper 32-bit DOS environment. I was stuck with Pascal, but I loved it. A few assembly routines gave me the speed I needed to work on my own games. 😀