Commit Graph

14 Commits

Author SHA1 Message Date
Kartik Agaram f13576b5d2 6957
The final fix to the raytracing program involves rounding modes. It turns
out x86 processors round floats by default, unlike C which has trained
me to expect truncation. Rather than mess with the MXCSR register, I added
another instruction for truncation. Now milestone 3 emits perfectly correct
results.
2020-10-05 10:25:25 -07:00
Kartik Agaram 6453bbbff8 6913 - copying floats around 2020-09-30 23:12:39 -07:00
Kartik Agaram 656b840e7f 6911 - comparing floats
It turns out floating-point operations set different flags than most instructions.
We have to branch on them using unsigned jumps.

https://stackoverflow.com/questions/7057501/x86-assembler-floating-point-compare/7057771#7057771
2020-09-30 22:53:14 -07:00
Kartik Agaram d564633b24 6910 - emulate most floating-point operations 2020-09-30 22:09:26 -07:00
Kartik Agaram c8da2350c2 6888
Teach `bootstrap translate` about the new /xm32 and /x32 arguments.
2020-09-27 22:41:55 -07:00
Kartik Agaram eee09a5607 6887
subx.md distinguishes between operands and arguments. Let's use that terminology
more consistently in the sources.
2020-09-27 22:05:11 -07:00
Kartik Agaram f068bda98e 6886 - floating-point division 2020-09-27 21:39:50 -07:00
Kartik Agaram 31e6ed17f8 6885 - starting on floating-point instructions
I spent some time deciding on the instructions. x87 is a stack ISA, so
not a good fit for the rest of SubX. So we use SSE instead. They operate
on 32-bit floats, which seems like a good fit.

SSE has a bunch of instructions for operating on up to 4 floats at once.
We'll ignore all that and just focus on so-called scalar instructions.
2020-09-27 21:12:48 -07:00
Kartik Agaram 15b9880136 6727 - bugfix in a multiply instruction
Also more error-detection for this case all across the toolchain.
2020-08-22 14:35:44 -07:00
Kartik Agaram 8f256f1f2e 6090 - new instruction: multiply by immediate
This is a 3-operand instruction:
  r32 = rm32 * imm32

It looks like https://c9x.me/x86/html/file_module_x86_id_138.html has a
bug, implying the same opcode supports a 2-operand version. I don't see
that in the Intel manual pdf, or at alternative sites like https://www.felixcloutier.com/x86/imul

Native runs seem to validate my understanding.

In the process I also fixed a bug in the existing multiply instruction
0f af: the only flags it sets are OF and CF. The other existing multiply
instruction f7 was doing things right.
2020-03-06 18:34:27 -08:00
Kartik Agaram 5c26afb1de 6088 - start using setCC instructions 2020-03-06 17:42:17 -08:00
Kartik Agaram 9eac92069d 5957 - bootstrap: stale checks for 2-byte opcodes 2020-01-30 00:02:53 -08:00
Kartik Agaram 19e7a418c9 5956 2020-01-29 23:57:45 -08:00
Kartik Agaram dc8790941e 5670 2019-09-19 15:26:24 -07:00