Skip to main content


if you aren't a huge fucking nerd you might not be aware that we spend way too much time debating the pros and cons of operating system types that will probably never leave the basements they were dreamed up in.

in my case, the design is of such an obscure type that there isn't much literature on the topic outside a handful of computer science research labs. as you can imagine there's no common parlance for something so odd, but I use the term "language kernel" or langkernel. not to be confused with an exokernel, through they can share some minor design patterns ^^

#theWorkshop

in reply to es q soy una chica, super poderosa

the way this works is that all of the operating system facilities are provided as language features. including managing access to low-level hardware access. in #tomo, for example, the cpu is completely virtual and garbage collected. the os does eventually generate machine code or interpret instructions, depending on the runtime settings, but as a programmer or user everything is presented through the lens of the language environment.

some programmers might find this distasteful, but that's ok. inside the os all of the regular low level stuff is possible and can easily be added or accessed through a device. the goal is to keep this collection of potentially unsafe trusted code as small as possible. the language environment works towards a similar goal by forcing everything to be done in a shared language runtime. like on the java vm, you can still use a variety of languages but everything ends up interoperable and runs on the same engine!

#tomo
in reply to es q soy una chica, super poderosa

one of my development goals is to move away from the limbo runtime and replace it with a new engine based on a combination of scheme and forth. this is very much inspired by prescheme and nanopass compiler development. learning about APL and BQN (especially co-dfns) has thrown me through a loop, so i might be revisiting some of this because data parallelism is something that i would love to have access to for scientific programming stuff that i want to do in the future.
in reply to Devine Lu Linvega

@neauoire i haven't quite landed on how i want the forth part to work, but in order to have the nanopass or prescheme optimizations happen it'll have to end up expressed as a scheme dialect at some point. its very likely that i'll end up with something that looks like joy.

i want something that i can use to explore the dis vm runtime context at a very low level. i'll probably end up doing a couple of different forths that don't have anything to do with scheme while i'm working on the project tbh.

This entry was edited (9 months ago)
in reply to es q soy una chica, super poderosa

the dis vm is similar to the chip in the newton cpu right? There might already a forth implementation targeting it, have you had a look?
in reply to Devine Lu Linvega

@neauoire i think dis is somewhere between CISC and VLIW, newton is an ARM chip i think? dis is surprisingly high level in certain areas. like car, cdr, and cons are all there in the isc. you can also do CSP operations like create and communicate over channels. its pretty neat.

http://doc.cat-v.org/inferno/4th_edition/dis_VM_specification

i haven't found any forths targeting it, but i might have missed it! that would be neat to stumble upon.

in reply to es q soy una chica, super poderosa

Ah yeah it's the Hobbit 😀

https://en.wikipedia.org/wiki/AT%26T_Hobbit

One side effect of the Hobbit design is that it inspired designers of the Dis virtual machine (an offshoot of Plan 9 from Bell Labs) to use a memory-to-memory-based system that more closely matches the internal register-based workings of real-world processors.

Lo, thar be cookies on this site to keep track of your login. By clicking 'okay', you are CONSENTING to this.