Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: GDSL – 800 line kernel: Lisp subset in 500, C subset in 1300

firthemouse.github.io

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Show HN: GDSL – 800 line kernel: Lisp subset in 500, C subset in 1300

#11

Post by FirTheMouse »

QuadmasterXLII wrote: post #10

where does it generate assembly assembly / llvm ir / machine code? I poked around and didn’t immediately spot this, or even which it targets.

That's the MIX. As mentioned in the README I haven't setup a system for these yet, just made the scaffolding, as a lot of the work in this space is actually around just the MIX layer. I'll probably be posting about more backend systems once I get started on making them, this project has only been in the works for 5 weeks so far. Though I would invite anyone interested to contribute a MIX module, that's where I have the least expertise.

Re: Show HN: GDSL – 800 line kernel: Lisp subset in 500, C subset in 1300

#12

Post by QuadmasterXLII »

FirTheMouse wrote: post #11
QuadmasterXLII wrote: post #10

where does it generate assembly assembly / llvm ir / machine code? I poked around and didn’t immediately spot this, or even which it targets.

That's the MIX. As mentioned in the README I haven't setup a system for these yet, just made the scaffolding, as a lot of the work in this space is actually around just the MIX layer. I'll probably be posting about more backend systems once I get started on making them, this project has only been in the works for 5 weeks so far. Though I would invite anyone interested to contribute a MIX module, that's where I have t…

Right, but like which one does it do in the demo?

Re: Show HN: GDSL – 800 line kernel: Lisp subset in 500, C subset in 1300

#13

Post by FirTheMouse »

QuadmasterXLII wrote: post #12
FirTheMouse wrote: post #11

Earlier quoted context omitted.

That's the MIX. As mentioned in the README I haven't setup a system for these yet, just made the scaffolding, as a lot of the work in this space is actually around just the MIX layer. I'll probably be posting about more backend systems once I get started on making them, this project has only been in the works for 5 weeks so far. Though I would invite anyone interested to contribute a MIX module, that's where I have t…

Right, but like which one does it do in the demo?

The demos run as interpreted trees through the x stage, no code emission yet, just direct execution of the AST. That's why they're demos rather than compilers. The scaffolding for native emission is there but empty.

Re: Show HN: GDSL – 800 line kernel: Lisp subset in 500, C subset in 1300

#14

Post by getpokedagain »

akkartik wrote: post #2

Looks interesting. The next step may be to show some little fun examples built with it. Here's my similar project from a few years ago, in case you want to compare notes: https://github.com/akkartik/mu https://akkartik.name/akkartik-convivial-20200607.pdf

Good to see you kicking around and here in a thread about things small enough to think about! I've not seen any blog posts from you in a while Kartik but I come back to your lua musings from time to time.

Re: Show HN: GDSL – 800 line kernel: Lisp subset in 500, C subset in 1300

#15

Post by akkartik »

getpokedagain wrote: post #14
akkartik wrote: post #2

Looks interesting. The next step may be to show some little fun examples built with it. Here's my similar project from a few years ago, in case you want to compare notes: https://github.com/akkartik/mu https://akkartik.name/akkartik-convivial-20200607.pdf

Good to see you kicking around and here in a thread about things small enough to think about! I've not seen any blog posts from you in a while Kartik but I come back to your lua musings from time to time.

You made my day with your kind words! I don't know if we've spoken before, but feel free to hit me up offline if you'd like to chat more about stuff like this.

Re: Show HN: GDSL – 800 line kernel: Lisp subset in 500, C subset in 1300

#17

Post by FirTheMouse »

stainlu wrote: post #16

[flagged]

My thoughts exactly, and it's what I intend to test in the coming weeks. I say 'subset' because the point isn't "here's a full C compiler" it's "here's two wildly different frontends handled by one system". I tried to get started on the backend this Friday, but got frustrated with the restrictions of running on a Mac, I wanted to go down lower and work from the metal for this, so I'm waiting to get access to a device I can start programming an OS on. If I find success, I'll definitely be posting about it. In the meantime though, I am more than open to anyone interested in helping on the backend, it's the biggest gap in my abilities and a new domain for me.

Re: Show HN: GDSL – 800 line kernel: Lisp subset in 500, C subset in 1300

#18

Post by FirTheMouse »

kaihong_deng wrote: post #7

Really interesting writeup. What stood out to me most was the shift from the earlier node execution path to the streamed path. The benchmark gap between execute_r_nodes and execute_stream is huge, and the latter getting relatively close to the handwritten C++ baseline is the part I keep thinking about. After building this, where do you think most compiler complexity actually comes from? My impression from your post i…

The streaming (essentially a JIT) was actually from the early architecture three weeks ago. Though I'm glad you've read even the first post. On the current architecture performance hasn't been a target yet, though the core hasn't changed, I could build a MIX that streams and it would reach the same benchmark.

And I love the question. A lot of the complexity is coming from the management of seams, places where we have to go from one representation of information to another. The tooling, diagnostics, and optimization passes are as large as they are precisely because of these seams. Consider a liveness pass in LLVM, which spends a lot of time reconstructing information thrown away by the compiler so it could emit SSA. In GDSL, a liveness pass is simply handlers in the e_stage, in the example I snuck into GDSL-C print statements stamp liveness tokens onto their children via qualifiers and at assignment nodes, those without such tokens are killed. I can do the logic in a straightforward manner because we have all the information to work with, no seams, no SSA to derive scopes from, thus why a subset of it fits in 80 lines instead of 80,000.

Re: Show HN: GDSL – 800 line kernel: Lisp subset in 500, C subset in 1300

#20

Post by sparkie »

swaminarayan wrote: post #19

If a working compiler can be written in ~1000 lines, why are production compilers like GCC or LLVM millions of lines?

They have dozens of passes for semantic analysis and optimization, often configurable via flags, and they target dozens of different architectures.
Post reply on HN