about summary refs log tree commit diff stats
path: root/033check_operands.cc
Commit message (Collapse)AuthorAgeFilesLines
* 6957Kartik Agaram2020-10-051-0/+1
| | | | | | | | 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.
* 6913 - copying floats aroundKartik Agaram2020-09-301-0/+2
|
* 6911 - comparing floatsKartik Agaram2020-09-301-1/+2
| | | | | | | 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
* 6910 - emulate most floating-point operationsKartik Agaram2020-09-301-2/+11
|
* 6888Kartik Agaram2020-09-271-4/+13
| | | | Teach `bootstrap translate` about the new /xm32 and /x32 arguments.
* 6887Kartik Agaram2020-09-271-226/+226
| | | | | subx.md distinguishes between operands and arguments. Let's use that terminology more consistently in the sources.
* 6886 - floating-point divisionKartik Agaram2020-09-271-0/+1
|
* 6885 - starting on floating-point instructionsKartik Agaram2020-09-271-2/+64
| | | | | | | | | 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.
* 6727 - bugfix in a multiply instructionKartik Agaram2020-08-221-1/+1
| | | | Also more error-detection for this case all across the toolchain.
* 6090 - new instruction: multiply by immediateKartik Agaram2020-03-061-0/+5
| | | | | | | | | | | | | | | 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.
* 6088 - start using setCC instructionsKartik Agaram2020-03-061-0/+11
|
* 5957 - bootstrap: stale checks for 2-byte opcodesKartik Agaram2020-01-301-2/+14
|
* 5956Kartik Agaram2020-01-291-27/+9
|
* 5670Kartik Agaram2019-09-191-0/+691