freenode/#sicl - IRC Chatlog
Search
11:40:00
lukego
though maybe it's more practical to define an idealized protocol for communicating with those devices - "plan 9 style" - and have a box that does the relevant messy conversion e.g. a raspberrypi running Linux.
11:41:19
lukego
but I guess that "bare metal" discussions can go meta pretty quickly e.g. when "metal" becomes "qemu" which is really just a piece of software providing arcane legacy ABIs based on historical hardware systems, etc.
11:53:15
lukego
SqueakNOS is an interesting project in the Dan Ingalls tradition: http://squeaknos.blogspot.com/. Interesting that it's still going, I looked at it many years ago and they were writing serious driver code etc in the full interactive/introspective Smalltalk world (as people describe Genera.) But I think Dan Ingalls himself just does Javascript-based stuff these days.
11:54:08
no-defun-allowed
Am I looking in the right place (SourceForge) to see that "it's still going"?
11:54:51
no-defun-allowed
Sadly when I tried to boot SqueakNOS in a VM and on an old laptop, it was unresponsive after rendering the Squeak desktop.
11:56:40
lukego
fwiw the last time I went down this route my compromise was to target the OLPC XO and use the Forth firmware as the bottom layer. I got Squeak running on that pretty OK and integrated with the hardware blitter IIRC. I lost that code though. But I still have related code doing the same stuff for a toy non-interactive smalltalk dialect at https://github.com/lukego/xoos/tree/master/xoos
11:57:12
lukego
but OLPC XO is a pretty random target especially these days, I guess e.g. Raspberry Pi would make a lot more sense if there's some similar layer available for that.
11:58:18
lukego
XO was nice because the AMD Geode chipset was simple and easy to program e.g. once you add PEEK and POKE primitives to the language you can drive the graphics hardware quite easily e.g. https://github.com/lukego/xoos/blob/master/xoos/Geode.st
11:58:44
lukego
so even the layer of Forth code was pretty thin because the hardware interfaces were pretty sane.
11:59:42
lukego
guessing RPi is not so amenable although maybe that new chip that RPi Foundation did from scratch could be interesting? quite a far cry from an "Alto" though
12:04:44
lukego
aside: I'm going down a multi-year rabbit hole now because the time I've spent writing drivers in recent years has basically convinced me that "people who are serious about software should build their own hardware" (- Alan Kay) i.e. life is too short to write drivers for other people's hardware that was usually made with sane driver interfaces as a low priority.
12:09:13
lukego
case in point: OLPC XO 1.0 had a really nice AMD Geode SoC with sane hardware interfaces all nicely documented publicly, and then the very next iteration 1.5 had a VIA SoC that was pure misery but won on price/performance (the Geode was horrifically slow -- maybe they "wasted" too much engineering time on making the driver interface good.)
12:13:14
lukego
(please excuse that extended braindump, forgot how much I have been obsessing about all things "high level languages on bare metal" over the years, love everything in this space :))
12:19:45
scymtym
who doesn't? that's why i thought https://www.youtube.com/watch?v=cooTl4-9bhg would be an interesting encore for the clouseau presentation
12:30:14
lukego
it's also a bit of a reality check though. I dream about a LispOS... and then suddenly there are multiple to choose from - OpenGenera, Movitz, Mezzano - and I don't actually bother to run them. I think that ultimately what I want is a Lisp machine that enables me to do something new that I couldn't do before -- but I'm not sure what that would be.
12:33:59
no-defun-allowed
Picking up CL let me imagine a few new things, but I don't know if an operating system (or lack thereof) would take it any further. In the case of CLOSOS, most of the language is just "more" of what I already know (barring first class global environments again).
12:37:49
no-defun-allowed
Maybe even the first part of that is debatable; debating linguistic relativity is a bit old by now though.
12:38:08
lukego
I think that I'd be attracted by an OS that came with a good stable hardware platform that I could get invested in. the OLPC was a bit like that although not really ideal. the Amiga was /exactly/ like that but that's been dead for decades now
12:39:12
lukego
Maybe I'll connect with this again... currently I'm writing Lisp code to help me create powerful FPGA boards for a fraction of the normal price, then I want to write Lisp code for programming FPGAs, maybe this could become a Lisp machine :)
12:41:30
lukego
and maybe if the hardware were actually defined by Lisp code and synthesized onto an FPGA that would tick the "lets me do something new" box. but hard to know ahead of time.
19:53:12
karlosz
i wouldn't flush it because you might still want (lambda (x) (the fixnum x) y) to do a runtime check
19:59:43
Bike
it's involved in a snag i hit while removing rtypes. i guess to figure out if a thei needs actual multiple values i need to look at the type?
20:00:52
Bike
there's only one bit of code in clasp's extended sequences library (why? i don't know) that hits this
20:01:09
karlosz
if we ironed out our use of values types vs non values types everywhere it should be possible to just find out if its unknown-values from looking at the types of the outputs and stuff
20:07:12
Bike
i thought sbcl only gave up checking on things like values &rest types, which nobody uses anyway
20:07:43
karlosz
sbcl can do more types of conflicting i believe, and i think there are some oddities with the representation i ended up choosing for thei checking
20:08:07
karlosz
Bike: yeah, the values &rest checking is too hairy to check, and we have the same problem, except instead of saying its too hairy i think we do the wrong thing?
20:10:28
Bike
how does it work now? like, there's the type check function, and it's mv-called? and then returns the values, or no?
20:17:07
Bike
i thought the translation layer in clasp was the only thing that actually needed rtypes
20:27:07
karlosz
i was thinking the type check generation should just be thrown into mir altogether?
20:28:11
Bike
thei should be an identity possibly with side effects. so it needs multiple values if its output does. but there are some other optimizations possible, like if we infer the input is one value
20:34:40
Bike
how about - if thei doesn't have a type check function, it has the same rtype (or rather needs values coerced in the same way) as whatever it outputs to. if it does, we could always have it accept multiple values, and then pick off other cases based on inference
20:35:49
Bike
i think i'll just do that since if there's a type check it doesn't need to be enormously fast anyway, so extra values thrown around are whatever
20:37:03
Bike
then i can have generate-type-check always do the mv call rather than checking the rtype
20:39:50
Bike
karlosz: although - what's the deal with a tcfunction of :external? i don't understand your comment.
20:53:42
Bike
hang on. actually. if we do this then the optimizations we want to do are the same as we want for ANY mv call, i think
20:54:03
Bike
like if we have (mvc type-check-function form), and derive that form returns exactly one value, we make it into (funcall type-check-function form)
20:56:11
Bike
and similar for the return values, since ideally we would have local calls not forcing everything into unknown values returns like it does now
20:58:29
karlosz
Bike: :external is kinda a hack for compile time checking arguments of inlined function. the commit might explain it better
20:59:14
karlosz
yeah in sbcl all the decisions for whether to do unknown values or known values stuff is driven off of the ctypes of lvars
21:35:03
Bike
i guess this is how we can do type check functions correctly and performantly. first, we write the functions to return all values, by doing something stupid like (multiple-value-call #'values ,@required (values-list ignore)). then we derive the type of ignore to be NIL (if we figure out the number of values), which lets that be reduced to (multiple-value-call #'values ,@required), which is just (values