1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
|
#+title: TODOs
#+author: Aryadev Chavali
#+date: 2023-11-02
* TODO Preprocessing directives :ASM:
Like in FASM or NASM where we can give certain helpful instructions to
the assembler. I'd use the ~%~ symbol to designate preprocessor
directives.
** DONE Constants
Essentially a directive which assigns some literal to a symbol as a
constant. Something like
#+begin_src asm
%const(n) 20 %end
#+end_src
Then, during my program I could use it like so
#+begin_src asm
...
push.word $n
print.word
#+end_src
The preprocessor should convert this to the equivalent code of
#+begin_src asm
...
push.word 20
print.word
#+end_src
2023-11-04: You could even put full program instructions for a
constant potentially
#+begin_src asm
%const(print-1)
push.word 1
print.word
%end
#+end_src
which when referred to (by ~$print-1~) would insert the bytecode given
inline.
* TODO Standard library :ASM:VM:
I should start considering this and how a user may use it. Should it
be an option in the VM and/or assembler binaries (i.e. a flag) or
something the user has to specify in their source files?
Something to consider is /static/ and /dynamic/ "linking" i.e.:
+ Static linking: assembler inserts all used library definitions into
the bytecode output directly
+ We could insert all of it at the start of the bytecode file, and
with [[*Start points][Start points]] this won't interfere with
user code
+ 2023-11-03: Finishing the Start point feature has made these
features more tenable. A program header which is compiled and
interpreted in bytecode works wonders.
+ Furthermore library code will have fixed program addresses (always
at the start) so we'll know at start of assembler runtime where to
resolve standard library subroutine calls
+ Virtual machine needs no changes to do this
+ Dynamic linking: virtual machine has fixed program storage for
library code (a ROM), and assembler makes jump references
specifically for this program storage
+ When assembling subroutine calls, just need to put references to
this library storage (some kind of shared state between VM and
assembler to know what these references are)
+ VM needs to manage a ROM of some kind for library code
+ How do we ensure assembled links to subroutine calls don't
conflict with user code jumps?
+ Possibility: most significant bit of a program address is
reserved such that if 0 it refers to user code and if 1 it
refers to library code
+ 63 bit references user code (not a lot of loss in precision)
+ Easy to check if a reference is a library reference or a user
code reference by checking "sign bit" (negativity)
** TODO Dynamic Linking
The address operand of every program control instruction (~CALL~,
~JUMP~, ~JUMP.IF~) has a specific encoding if the standard library is
dynamically linked:
+ If the most significant bit is 0, the remaining 63 bits encode an
absolute address within the program
+ Otherwise, the address encodes a standard library subroutine. The
bits within the address follow this schema:
+ The next 15 bits (7 from the most significant byte, then 8 from
the next byte) represent the specific module where the subroutine
is defined (over 32767 possible library values)
+ The remaining 48 bits (6 bytes) encode the absolute program
address in the bytecode of that specific module for the start of
the subroutine (over 281 *trillion* values)
The assembler will automatically encode this based on "%USE" calls and
the name of the subroutines called.
On the virtual machine, there is a storage location (similar to the
ROM of real machines) which stores the bytecode for modules of the
standard library, indexed by the module number. This means, on
deserialising the address into the proper components, the VM can refer
to the module bytecode then jump to the correct address.
2023-11-09: I'll need a way to run library code in the current program
system in the runtime. It currently doesn't support jumps or work in
programs outside of the main one unfortunately. Any proper work done
in this area requires some proper refactoring.
2023-11-09: Constants or inline macros need to be reconfigured for
this to work: at parse time, we work out the inlines directly which
means compiling bytecode with "standard library" macros will not work
as they won't be in the token stream. Either we don't allow
preprocessor work in the standard library at all (which is bad cos we
can't then set standard limits or other useful things) or we insert
them into the registries at parse time for use in program parsing
(which not only requires assembler refactoring to figure out what
libraries are used (to pull definitions from) but also requires making
macros "recognisable" in bytecode because they're essentially
invisible).
* TODO Explicit symbols in bytecode :VM:ASM:
A problem, arising mainly from the standard library, is that symbols
such as constants/macros or subroutines aren't explicit in the
bytecode: the assembler parses them away into absolute addresses and
standard bytecode. They aren't exposed at all in the bytecode, which
means any resolution for "linking" with other assembled objects
becomes a hassle.
Constants and macros currently compile down to just base instructions,
which means the symbols representing them (the "names") are compiled
down to an absolute equivalent:
+ macros and constants compile to the tokens supplied, feeding the
parser
+ labels and relative addresses are compiled to absolute program
addresses, dealt with in the parser, constructing tokens
In either case once the code has been compiled, there is no memory of
symbols within it.
For user space programs one could figure out a way to decompose the
bytecode into "symbols", currently, as they must be present in the
bytecode, which means they have an absolute address in the program,
hence it's pretty easy to figure out when a program control
instruction uses a label.
However, for something like "using multiple files" or the standard
library some further thought is needed. Therefore
* Completed
** DONE Write a label/jump system :ASM:
Essentially a user should be able to write arbitrary labels (maybe
through ~label x~ or ~x:~ syntax) which can be referred to by ~jump~.
It'll purely be on the assembler side as a processing step, where the
emitted bytecode purely refers to absolute addresses; the VM should
just be dealing with absolute addresses here.
** DONE Allow relative addresses in jumps :ASM:
As requested, a special syntax for relative address jumps. Sometimes
it's a bit nicer than a label.
** DONE Calling and returning control flow :VM: :ASM:
When writing library code we won't know the addresses of where
callers are jumping from. However, most library functions want to
return control flow back to where the user had called them: we want
the code to act almost like an inline function.
There are two ways I can think of achieving this:
+ Some extra syntax around labels (something like ~@inline <label>:~)
which tells the assembly processor to inline the label when a "jump"
to that label is given
+ This requires no changes to the VM, which keeps it simple, but a
major change to the assembler to be able to inline code. However,
the work on writing a label system and relative addresses should
provide some insight into how this could be possible.
+ A /call stack/ and two new syntactic constructs ~call~ and ~ret~
which work like so:
+ When ~call <label>~ is encountered, the next program address is
pushed onto the call stack and control flow is set to the label
+ During execution of the ~<label>~, when a ~ret~ is encountered,
pop an address off the call stack and set control flow to that
address
+ This simulates the notion of "calling" and "returning from" a
function in classical languages, but requires more machinery on
the VM side.
** DONE Start points :ASM:VM:
You know how in standard assembly you can write
#+begin_src asm
global _start
_start:
...
#+end_src
and that means the label ~_start~ is the point the program should
start from. This means the user can define other code anywhere in the
program and specify something similar to "main" in C programs.
Proposed syntax:
#+begin_src asm
init <label>
#+end_src
|
