| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
At the SubX level we have to put up with null-terminated kernel strings
for commandline args. But so far we haven't done much with them. Rather
than try to support them we'll just convert them transparently to standard
length-prefixed strings.
In the process I realized that it's not quite right to treat the combination
of argc and argv as an array of kernel strings. Argc counts the number
of elements, whereas the length of an array is usually denominated in bytes.
|
| |
|
|
|
| |
I had to amend commit 6148 three times yesterday as I kept finding bugs
by inspection. And yet I stubbornly thought I didn't need a test.
|
| | |
|
| |
|
|
| |
This is quite inefficient; don't use it for very large objects.
|
| | |
|
| | |
|
| |
|
|
|
| |
This could be a can of worms, but I think I have a set of checks that will
keep use of addresses type-safe.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Using these is quite unsafe. But what isn't, here?
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I built this in 3 phases:
a) create a helper in the bootstrap VM to render the state of the stack.
b) interactively arrive at the right function (tools/stack_array.subx)
c) pull the final solution into the standard library (093stack_allocate.subx)
As the final layer says, this may not be the fastest approach for most
(or indeed any) Mu programs. Perhaps it's better on balance for the compiler
to just emit n/4 `push` instructions.
(I'm sure this solution can be optimized further.)
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It makes no sense to know where the next variable will start before I've
seen it or how much space it needs. Things have only been working so far
because all variables take 4 bytes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We can't do it during parsing time because we may not have all type definitions
available yet. Mu supports using types before defining them.
At first I thought I should do it in populate-mu-type-sizes (appropriately
renamed). But there's enough complexity to tracking when stuff lands on
the stack that it's easiest to do while emitting code.
I don't think we need this information earlier in the compiler. If I'm
right, it seems simpler to colocate the computation of state close to where
it's used.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Move computation of offsets to record fields into the new phase as well.
Now we should be robust to type definitions in any order.
|
| |
|
|
|
|
|
|
|
|
| |
Move out total-size computation from parsing to a separate phase.
I don't have any new tests yet, but it's encouraging that existing tests
continue to pass.
This may be the first time I've ever written this much machine code (with
mutual recursion!) and gotten it to work the first time.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Finally we're now able to track the index of a field in a record/struct/product
type.
|
| |
|
|
| |
Free up eax using the newly available register.
|
| |
|
|
| |
Create space for another local.
|
| |
|
|
|
| |
parse-mu-types has a lot of local state. Move a local to the stack to free
up a register.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Make room for additional information for each field in a record/product
type.
Fields can be used before they're declared, and we may not know the offsets
they correspond to at that point. This is going to necessitate a lot of
restructuring.
|
| |
|
|
| |
Fix a bug with a live register being clobbered.
|
| | |
|
| |
|
|
| |
A new test, and a new bugfix.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Some much-needed reorganization.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|