[HN Gopher] Konilo: A personal computing system in Forth
___________________________________________________________________
Konilo: A personal computing system in Forth
Author : marttt
Score : 134 points
Date : 2024-03-02 06:25 UTC (16 hours ago)
(HTM) web link (konilo.org)
(TXT) w3m dump (konilo.org)
| malicka wrote:
| Interesting project! I've never gotten past brief tinkering with
| Forth, so this might be a good excuse to get a little farther.
|
| It's named in Esperanto, too -- "ilo" being "tool," "koni" being
| "to know," and so "Kon/il/o" meaning a "tool for knowing."
| kristianp wrote:
| I give a little chuckle whenever someone mentions Esperanto.
| It's the official language in the tv show Red Dwarf and Rimmer
| always struggles to use it. Its a bit of an ongoing joke.
| mark_l_watson wrote:
| That is kool. I was really into Forth in 1978 when I bought an
| Apple II, serial number was 72. I was going to port Forth to my
| Apple but two guys at Computer Land in San Diego dissed the idea,
| saying there were a few ports already. I was young and stupid and
| actually cared about what other people said. I ended up six
| months later going deep in every Lisp language implementation I
| could get access to, and that changed my tech life. Anyway,
| Konilo looks cool!
| pvg wrote:
| Did you eventually run across GraFORTH by fellow HN'er lutusp?
|
| https://archive.org/details/a2_GraFORTH_1981_Lutus_Paul
| alexisread wrote:
| OOI, this bytecode VM uses 30 instructions while something like
| Freeforth has 55 forth instructions- is it actually worth having
| a bytecode VM under the forth VM?
|
| Arguments for are that you could migrate processes easier, and
| I/O has a std interface. But against that it's not native code.
|
| I'm struggling with defining the instruction set for my own
| forth-style VM.
| stevekemp wrote:
| I think the instruction set, or the minimum number of
| primitives you need to implement in the "host" not the language
| itself is fascinating.
|
| I've looked at a lot of implementations that have a DROP
| definition like this, for example: : drop ( x
| y -- x ) dup - + ;
|
| That works UNLESS your stack has only a single value on it.
| Things like this get simpler if you have a variable pointing to
| the top of the stack where you can just change that - but
| otherwise you end up having to implement DROP as a built-in.
|
| You can obviously implement "<" in terms of ">", and if you can
| multiply by -1 you can implement subtraction in terms of
| addition, but at the same time writing "-" is no harder than
| writing "+", if you're not targeting a small CPU like a Z80.
|
| I love to compare implementations, to see which core primitives
| they've chosen, and explore the consequences. These days I
| think my interest is more in implementing FORTH than actually
| using it, but I suspect I'm not alone in that regard!
| alexisread wrote:
| Agreed, the implementation is the fun part!
|
| Obviously instructions can be chosen for efficiency, else
| we'd all be using the 7 instructions of sectorforth. In fact
| freeforth has additional instructions for register renaming
| (to avoid SWAP instructions).
|
| So what's a good set? Most seem to have 25-30 (Mako, Retro,
| Jones, Stoneknife)
| uticus wrote:
| > Most seem to have 25-30 (Mako, Retro, Jones, Stoneknife)
|
| Know of any good sources that catalogue these? If it's all
| in your noggin I respect that, but had to ask.
| alexisread wrote:
| Not any sources/overview as such, I just looked at the VM
| code.
|
| So for Mako: https://github.com/JohnEarnest/Mako/blob/mas
| ter/src/MakoVM.j...
|
| Freeforth: https://github.com/dan4thewin/FreeForth2/blob/
| master/ff.asm
|
| Jonesforth: https://github.com/nornagon/jonesforth/blob/m
| aster/jonesfort...
|
| Stoneknife: https://github.com/kragen/stoneknifeforth/blo
| b/master/tinybo...
|
| Retro/Ilo: http://ilo.retroforth.org/ilo.txt
|
| Sectorforth:https://github.com/cesarblum/sectorforth/blob
| /master/sectorf... but see:
| https://github.com/cesarblum/sectorforth/issues/6 and:
| https://github.com/cesarblum/sectorforth/issues/8
| packetlost wrote:
| This reminds me of the Uxn from 100r. I'm always happy to see
| more FORTH-ish languages on my feed
| z5h wrote:
| 100r have really set the bar for what stack language/VM I would
| actually play with if I had the time. I see how it can
| immediately be useful for writing GUI/music/etc apps. And the
| instructions/guides are sooo good.
| MegaSec wrote:
| Neat name. It's probably just a coincidence, but "konilo" means
| "knowing machine" in Esperanto.
| vitiral wrote:
| I highly doubt that is a coincidence
| filipeherculano wrote:
| Random question: what font did you use to make that Konilo logo?
| It's gorgeous.
| millsteed wrote:
| I think it's Adorn Roman by Laura Worthington.
| ilaksh wrote:
| Does it have my graphics support?I think something with low
| resource requirements like this might be good for running on a
| pair of AR/MR glasses.
| frompdx wrote:
| I have not personally used this Forth, but I would like to point
| out some very nice differences between existing implementations.
|
| - Permissive license. Other Forths such as FlashForth for the
| Arduino are copy-left.
|
| - Direct threaded code. Faster execution compared to traditional
| indirect threaded Forth.
|
| - Out of the box support for x86 and an inexpensive ARM
| microcontroller.
|
| I definitely think I'll pick up a Teensy to test this out to see
| how it compares to working with FlashForth on the Arduino.
| whartung wrote:
| It's interesting to contrast a "Forth OS" with a what might be
| considered a more conventional one. And by this I'm talking about
| early small machine systems like CP/M and its contemporaries.
|
| At a fundamental level, you had a kernel of some kind, and free
| space within which programs could be loaded and executed. With a
| Forth, you could get that with about 6K of total overhead.
|
| One of the big contrasts is that with Forth, at the time,
| programs were loaded from source code, whereas everyone else used
| binary code. But another interesting aspect was that in Forth,
| when you were done with a program, you had to free up the space,
| if necessary, to run another program. In something like CP/M,
| when a program was exited, the OS reclaimed the space, and, to
| run it again, the program would have to be reloaded from storage.
|
| The next big difference was the file system (or lack thereof).
| Forth does not have a file system, it simply organizes storage as
| a sequence of 1K blocks. It was common to have "table of
| contents" screens to track where programs were stored on disk,
| these all had to be manually maintained.
|
| CP/M had a much better file system, but its interesting to
| contrast it with the UCSD P-System, which had a very crude file
| system. While it indeed had named files, it suffered from
| requiring them to be contiguous, and really only allowing one
| file to be written at a time (not exactly true, but only one file
| could grow freely at a time -- the file "at the end"). However,
| reorganizing, and compacting free space was a routine task under
| the P-System.
|
| The Forth system being rock simple was quite easy to make a
| mistake and lose data, for example if you were relocating source
| code to make new space, you could easily overwrite something
| accidentally, since you were responsible for the actual disk
| locations of the operation.
|
| The final nice feature of the Forth system, speaking of disk
| blocks, was the crude virtual memory system. Here, disk blocks
| were arbitrarily mapped to memory buffers, with a simple LRU
| system, and dirty buffers automatically being flushed back to
| disk. This made persistent memory mechanics quite easy to use.
|
| Of course, for most micro users this was not as hazardous, as
| most of the work was done at the "floppy" level in contrast to
| working on a hard disk with 5000 screens. But that was the
| reality of native Forth systems of the day, and folks just worked
| with it, and leveraged it to get work done.
|
| The idea of those basic ideas being scaled up to a modern machine
| with GB of RAM and enormous hard disks is an interesting
| curiosity. It certainly gives you a lot of room to be sloppy.
| Such a system wouldn't happen, the frugal nature of those early
| Forth systems was no longer required, so adding complexity and
| space to make the userland more friendly is worth the investment.
| alexisread wrote:
| Sloppy, potentially, but what about an OO Forth with types and
| delimited continuations? That might tidy up many of the large
| scale footguns.
|
| Bear in mind that a small kernel would be handy for fitting
| into L1 caches and GPU units.
| tombert wrote:
| So, I have a kind of dumb question.
|
| As someone born after C and its derivatives took over the world,
| Forth has always been this "weird cool old language". It seems
| like Forth was this very beloved language by a small set of
| enthusiasts, but I'm not entirely sure why.
|
| I also cannot quite tell if it's a high-level or low-level
| language, though maybe that's the point? It definitely seems like
| it might be worth learning for the retro computing development
| world. Is my understanding correct?
| smackeyacky wrote:
| It's a high level language compared to Assembler. Like a lot of
| those early experimental languages it's worth learning a bit.
| It's also a pretty much complete failure other than a few
| standout uses (the main one I can think of is that the boot
| loader on Sun SPARC machines was written in Forth).
|
| To me it fits in an odd place. It was much hyped/replicated on
| Micros in the 1980s as it made the Basic implementations on
| those machines seem very old fashioned. For most users who were
| already working on minicomputers in languages like C or Lisp,
| Forth was just a weird riff on stack based languages that had
| already been considered and discarded. So the general
| impression on whether Forth was any good or not depended
| entirely on what else you had programmed in.
|
| Having said that, stack based languages like Forth, PostScript
| or even xslt are challenging and thought provoking.
|
| Personally, if I wanted to play with a stack based language I'd
| play with PostScript or xslt as at least you'd have half a
| chance to use it professionally.
|
| edit: yeah xslt isn't a stack based language but I always
| thought it helped when learning it to consider it that way
| tombert wrote:
| I've wanted to write some retro computer games for awhile,
| but I really hate mucking with Assembly language. It would be
| cool to have something faster than BASIC but higher level
| than raw assembly.
___________________________________________________________________
(page generated 2024-03-02 23:00 UTC)