Thoughtophone

I've got multiple return values and apply working in Picobit, and that means Picobit can compile SRFI-1. This post to remind myself what I am trying to achieve, because this has been a long detour. I'm actually trying to get the time library in SRFI-19 working. It needs SRFI-6: string ports, SRFI-8: receive and by extension multiple values support. This is nothing to do with SRFI-1, other than it seemed like a good candidate for testing multiple values. My multiple values work like this: I created a 'values' type, which is just a wrapper around a list. (values ... ) returns one of these. Two primitives: (#%apply-call proc values) and (#%proc-jump proc values) apply a proc to values (jump is for tail calls). To get the two different primitives to be called in the right places, I added a new AST node type specifically for apply, and then matched it in the compilation phase. Having looked into SRFI-6, I now realise I don't have R5RS io primitives. Some of the nam...

I now have a scheme program that sets and gets the time from a TinyRTC connected to the STM32F4 discovery board. It's actually fairly neat. See examples/stm32f4-discovery-flash.scm  and tinyrtc.scm . I couldn't get it to work for ages, because I'd forgotten I needed to configure the pins in open drain mode, as well as configuring I2C mode. I'll have to go back and hack on the generated use-pin code so it does that automatically. That's pretty exciting though. Using map to convert lists from binary to BCD is a neat demonstration of the relevance of scheme, as is the fact that I'll eventually be able to automate pin configuration with some simple rules.

I've finally got source code references for Picobit byte code. It's proved enormously frustrating. My first approach attached the original syntax references to the structs used in the AST. After I'd done all this, I found only 2/3 of the tests passed. I made what seemed like a reasonable assumption: the front end uses lots of incomplete pattern matching on the structs. I'd tried to update all the patterns, but perhaps I missed some. I went back and replaced the front end approach with a dictionary from AST nodes to syntax. The result was exactly the same! This was worthwhile though: the pretty printing of the AST now matches in the original and new versions, so I can capture that and prove the front and is unchanged. I have a script which captures the AST and the assembler output for each test file. Now I can just run meld with the two output directories as arguments... There's one instruction I'm just not emitting: goto-if-false. Turns out that's ju...