History

Torsten Ruger 6433a394e7 adding receiver and a register abstraction		2014-06-06 21:49:03 +03:00
..
block.rb	that fixes the while. To work. Actually work. Fibonacci and all :-)	2014-05-23 20:27:14 +03:00
boot_class.rb	first oo program to compile. But no worries, there is still work left to be done	2014-06-05 18:17:00 +03:00
boot_memory.rb	renamed program to boot_space, as in object_space at boot time. thats the way its going	2014-05-31 12:52:29 +03:00
boot_space.rb	first oo program to compile. But no worries, there is still work left to be done	2014-06-05 18:17:00 +03:00
call_site.rb	first oo program to compile. But no worries, there is still work left to be done	2014-06-05 18:17:00 +03:00
code.rb	gives function the list of blocks it needs for branching and documents also the blocks better	2014-05-22 14:18:22 +03:00
constants.rb	first oo program to compile. But no worries, there is still work left to be done	2014-06-05 18:17:00 +03:00
context.rb	let the BootClasses carry functions, ie one level squeezed between object_space and funtion, the class is coming to life	2014-05-31 14:35:33 +03:00
function.rb	adding receiver and a register abstraction	2014-06-06 21:49:03 +03:00
instruction.rb	makes memory a three operand instruction, like add etc. But 3 regs are still undone	2014-06-01 21:20:44 +03:00
meta_class.rb	first oo program to compile. But no worries, there is still work left to be done	2014-06-05 18:17:00 +03:00
README.markdown	use crystal calling convention, documented in readme	2014-05-25 10:57:56 +03:00
register_machine.rb	makes memory a three operand instruction, like add etc. But 3 regs are still undone	2014-06-01 21:20:44 +03:00
values.rb	adding receiver and a register abstraction	2014-06-06 21:49:03 +03:00

README.markdown

Virtual Machine

This is the logic that uses the generated ast to produce code, using the asm layer.

Apart from shuffeling things around from one layer to the other, it keeps track about registers and provides the stack glue. All the stuff a compiler would usually do.

Also all syscalls are abstracted as functions.

The Crystal Convention

Since we're not in c, we use the regsters more suitably for our job:

return register is not the same as passing registers
we pin one more register (ala stack/fp) for type information (this is used for returns too)
one line (8 registers) can be used by a function (caller saved?)
rest are scratch and may not hold values during call

For Arm this works out as:

0 type word (for the line)
1-6 argument passing + workspace
7 return value

This means syscalls (using 7 for call number and 0 for return) must shuffle a little, but there's space to do it. Some more detail:

1 - returning in the same register as passing makes that one register a special case, which i want to avoid. shuffling it gets tricky and involves 2 moves for what? As i see it the benefitd of reusing the same register are one more argument register (not needed) and easy chaining of calls, which doen't really happen so much. On the plus side, not using the same register makes saving and restoring registers easy (to implement and understand!). An easy to understand policy is worth gold, as register mistakes are HARD to debug and not what i want to spend my time with just now. So that's settled.

2 - Tagging integers like MRI/BB is a hack which does not extend to other types, such as floats. So we don't use that and instead carry type information externally to the value. This is a burden off course, but then so is tagging. The convention (to make it easier) is to handle data in lines (8 words) and have one of them carry the type info for the other 7. This is also the object layout and so we reuse that code on the stack.