You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Create issues and project cards for the required steps
Compile and run the program
Just to make the goal clear for the "Hello world!" milestone, here's the test program:
use kernal
fun print(text: &[u8])
for c: u8 in text do
kernal.chrout(c)
end
endfun
fun main()
print("hello, world!\n")
endfun
Original commentary:
So, what's interesting here? Well, we have some basic control flow, a function call, all good. We have a slice. Additionally, we have a KERNAL call. KERNAL calls have "weird" (in jeff65 terms) calling conventions, so this could (provisionally) be done in a few ways:
kernal.chrout is a real, honest-to-god linker symbol with type fun(u8), value 0xffd2, and an associated calling convention.
kernal.chrout is a compiler intrinsic which emits the appropriate assembly directly.
kernal.chrout is a real function implemented in assembly which puts its argument in the A register and then does jsr $ffd2.
Each of this is interesting in a different way. Doing 1 right out of the gate means that we ensure that our code generation for function calls isn't hard-coded to a particular convention, but means we have to support two of them. Doing 2 might just be a bad idea--my gut feeling is that that's not really what compiler intrinsics are for. Doing 3 means that we implement the ability to (a) load the symbol table from referenced units and use it, and (b) link multiple units together. (I think technically we can already do that last thing, but there's no support for it in the command-line driver.)
Obviously 1 is the "correct" way to do it long-term, but 3 is good enough for now I think.
For bonus points, implement an "improvement" pass (NFCE terminology) which notices that the range variable c is only used as a function argument, and loads it directly into the argument slot for the kernal.chrout function.
The text was updated successfully, but these errors were encountered:
Woody, I've assigned this to you to review. Once we've decided on the actual goal, you can either assign it back to me to create the issues, or do it yourself, and then either hang onto the issue or un-assign it.
Just to make the goal clear for the "Hello world!" milestone, here's the test program:
Original commentary:
So, what's interesting here? Well, we have some basic control flow, a function call, all good. We have a slice. Additionally, we have a KERNAL call. KERNAL calls have "weird" (in jeff65 terms) calling conventions, so this could (provisionally) be done in a few ways:
fun(u8)
, value 0xffd2, and an associated calling convention.jsr $ffd2
.Each of this is interesting in a different way. Doing 1 right out of the gate means that we ensure that our code generation for function calls isn't hard-coded to a particular convention, but means we have to support two of them. Doing 2 might just be a bad idea--my gut feeling is that that's not really what compiler intrinsics are for. Doing 3 means that we implement the ability to (a) load the symbol table from referenced units and use it, and (b) link multiple units together. (I think technically we can already do that last thing, but there's no support for it in the command-line driver.)
Obviously 1 is the "correct" way to do it long-term, but 3 is good enough for now I think.
For bonus points, implement an "improvement" pass (NFCE terminology) which notices that the range variable
c
is only used as a function argument, and loads it directly into the argument slot for the kernal.chrout function.The text was updated successfully, but these errors were encountered: