Commit Graph

58 Commits

Author SHA1 Message Date
Kartik K. Agaram
c45371b319 compute-offset: literal index 2021-08-25 22:19:24 -07:00
Kartik K. Agaram
0ab5f6fb3a mu.subx: support bitwise not 2021-05-16 21:47:47 -07:00
Kartik K. Agaram
f9f419af71 support checking overflow flag everywhere 2021-05-08 21:49:50 -07:00
Kartik K. Agaram
888b4cd8ea always check for null in 'index' instructions 2021-05-07 21:04:45 -07:00
Kartik K. Agaram
e74050ade4 always check for null in 'get' instructions 2021-05-07 18:25:43 -07:00
Kartik Agaram
6dc9722704 7478 2021-01-03 22:38:41 -08:00
Kartik Agaram
4a280280cd 7296 - rough support for printing floats
No rounding yet, and we have a blunt way to decide when to start truncating.
2020-11-29 08:45:25 -08:00
Kartik Agaram
125bfde435 7286 - mu.subx: isolate bytes from previous values 2020-11-27 00:04:54 -08:00
Kartik Agaram
729800593a 7266 2020-11-17 22:05:45 -08:00
Kartik Agaram
1696ed831a 7261 - mu.subx: array bounds-checking done 2020-11-17 18:16:26 -08:00
Kartik Agaram
002f2609e9 7248 - mu.subx: new primitive 'clear-object' 2020-11-15 23:13:23 -08:00
Kartik Agaram
2715d377b6 7247 2020-11-15 22:54:56 -08:00
Kartik Agaram
ccadc6e604 7152 - 'return' instruction
https://github.com/akkartik/mu/issues/45#issuecomment-719990879, task 1.

We don't have checking for it yet. Soon.
2020-11-01 18:02:02 -08:00
Kartik Agaram
c3964ff60a 7150 2020-10-31 20:38:11 -07:00
Kartik Agaram
1323587822 7147 2020-10-31 19:55:33 -07:00
Kartik Agaram
3f30e4c6e6 7146 2020-10-31 19:50:41 -07:00
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
5c3d495dbe 6954 2020-10-05 09:28:19 -07:00
Kartik Agaram
21ff6d831a 6944 2020-10-04 01:25:02 -07:00
Kartik Agaram
611e9f2e08 6920 2020-10-01 00:49:09 -07:00
Kartik Agaram
8d32a9aab9 6915 - a new family of Mu branch instructions
The realization of commit 6916 means that we should be using jump-if-addr*
after comparing floats. Which is super ugly. Let's create aliases to them
called jump-if-float*.
2020-09-30 23:46:43 -07:00
Kartik Agaram
72c42f90cf 6908 - compiling all floating-point operations
We don't yet support emulating these instructions in `bootstrap`. But generated
binaries containing them run natively just fine.
2020-09-30 21:17:37 -07:00
Kartik Agaram
9aea89ba73 6896
Readme-driven development for Mu's floating-point operations.
2020-09-28 22:19:43 -07:00
Kartik Agaram
59391f2af4 6894 2020-09-28 20:11:40 -07:00
Kartik Agaram
db469acb3a 6893 2020-09-28 20:11:21 -07:00
Kartik Agaram
59a2e363f5 6698 2020-08-01 16:28:32 -07:00
Kartik Agaram
af983921f6 6697 2020-08-01 16:25:34 -07:00
Kartik Agaram
28b25a4893 6657 2020-07-16 22:34:57 -07:00
Kartik Agaram
ab26c894c8 6648 - bit-shift instructions in Mu
I'm not happy with the names.
2020-07-14 21:42:20 -07:00
Kartik Agaram
5e0ae917d0 6645 - heap allocations in Mu
- allocate var
- populate var, n

Both rely on the type of `var` to compute the size of the allocation. No
need to repeat the name of the type like in C, C++ or Java.
2020-07-13 22:21:26 -07:00
Kartik Agaram
ef845524e9 6516 - operations on bytes
Byte-oriented addressing is only supported in a couple of instructions
in SubX. As a result, variables of type 'byte' can't live on the stack,
or in registers 'esi' and 'edi'.
2020-06-13 20:23:51 -07:00
Kartik Agaram
b3998440f3 6468 2020-06-05 13:56:19 -07:00
Kartik Agaram
48d96636fa 6465 2020-06-04 21:17:11 -07:00
Kartik Agaram
985f7f79be 6408 2020-05-27 00:01:12 -07:00
Kartik Agaram
d796318101 6405 2020-05-25 00:58:12 -07:00
Kartik Agaram
27b1e19ebe 6392 - 'length' instruction done in all complexity 2020-05-24 19:46:47 -07:00
Kartik Agaram
156763463d 6390 - return length in elements 2020-05-24 14:48:41 -07:00
Kartik Agaram
d89af9bdfa 6389 2020-05-24 08:02:11 -07:00
Kartik Agaram
cbec147d3b 6173 2020-03-27 02:08:02 -07:00
Kartik Agaram
606c1ab49a 6170 2020-03-25 09:54:53 -07:00
Kartik Agaram
84c426d2ab 6169 2020-03-25 09:46:35 -07:00
Kartik Agaram
be19cb8772 6164 2020-03-24 03:49:56 -07:00
Kartik Agaram
0ef7f1d2d6 6160 - plan for safe heap access
Based on apps/handle.subx (commit 4894), but we're able to simplify it
further now that we know more about the situation we find ourselves in.
6 instructions, zero pushes or pops.

Before I can start building this, I need to reorganize my use of handles.
They're going to be fat pointers so we can't store them in registers anymore.
2020-03-21 22:43:43 -07:00
Kartik Agaram
fa80585024 6159 2020-03-21 17:26:31 -07:00
Kartik Agaram
df609237c1 6158 - standardize opcode names
At the lowest level, SubX without syntax sugar uses names without prepositions.
For example, 01 and 03 are both called 'add', irrespective of source and
destination operand. Horizontal space is at a premium, and we rely on the
comments at the end of each line to fully describe what is happening.

Above that, however, we standardize on a slightly different naming convention
across:
  a) SubX with syntax sugar,
  b) Mu, and
  c) the SubX code that the Mu compiler emits.

Conventions, in brief:
  - by default, the source is on the left and destination on the right.
    e.g. add %eax, 1/r32/ecx ("add eax to ecx")
  - prepositions reverse the direction.
    e.g. add-to %eax, 1/r32/ecx ("add ecx to eax")
         subtract-from %eax, 1/r32/ecx ("subtract ecx from eax")
  - by default, comparisons are left to right while 'compare<-' reverses.

Before, I was sometimes swapping args to make the operation more obvious,
but that would complicate the code-generation of the Mu compiler, and it's
nice to be able to read the output of the compiler just like hand-written
code.

One place where SubX differs from Mu: copy opcodes are called '<-' and
'->'. Hopefully that fits with the spirit of Mu rather than the letter
of the 'copy' and 'copy-to' instructions.
2020-03-21 16:51:52 -07:00
Kartik Agaram
114641e2c8 6145 - 'address' operator
This could be a can of worms, but I think I have a set of checks that will
keep use of addresses type-safe.
2020-03-14 14:46:45 -07:00
Kartik Agaram
92ca78429c 6131 - operating on arrays on the stack 2020-03-12 00:17:35 -07:00
Kartik Agaram
afc0be47a5 6129 2020-03-11 20:56:27 -07:00
Kartik Agaram
44798a2e2c 6097
I thought I needed to support compute-offset with literal index, but in
that case might as well just use an index literal directly. The 'index'
instruction with literals already supports non-power-of-2 sizes.
2020-03-07 19:55:03 -08:00
Kartik Agaram
3cf0315859 6094 - new 'compute-offset' instruction
If indexing into a type with power-of-2-sized elements we can access them
in one instruction:

  x/reg1: (addr int) <- index A/reg2: (addr array int), idx/reg3: int

This translates to a single instruction because x86 instructions support
an addressing mode with left-shifts.

For non-powers-of-2, however, we need a multiply. To keep things type-safe,
it is performed like this:

  x/reg1: (offset T) <- compute-offset A: (addr array T), idx: int
  y/reg2: (addr T) <- index A, x

An offset is just an int that is guaranteed to be a multiple of size-of(T).
Offsets can only be used in index instructions, and the types will eventually
be required to line up.

In the process, I have to expand Input-size because mu.subx is growing
big.
2020-03-07 17:40:45 -08:00