15 ms·

Konilo: A personal computing system in Forth

187 points by marttt 3y ago

malicka 3y ago
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 3y ago
  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.
  - ithkuil 3y ago
    Kaposmegulo!
mark_l_watson 3y ago
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 3y ago
  Did you eventually run across GraFORTH by fellow HN'er lutusp? https://archive.org/details/a2_GraFORTH_1981_Lutus_Paul https://archive.org/details/a2_GraFORTH_1981_Lutus_Paul
  - mikewarot 3y ago
    I remember typing in program into GraFORTH on my friend's Apple ][ as he read it to me. The resulting animation of the earth and the space shuttle opening its cargo doors was amazing back then. I'll never forget it.
  - mark_l_watson 3y ago
    Good question, but I don’t remember.
alexisread 3y ago
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 3y ago
  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 3y ago
    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 3y ago
      > 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.
packetlost 3y ago
This reminds me of the Uxn from 100r. I'm always happy to see more FORTH-ish languages on my feed
- z5h 3y ago
  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 3y ago
Neat name. It’s probably just a coincidence, but “konilo” means “knowing machine” in Esperanto.
- vitiral 3y ago
  I highly doubt that is a coincidence
filipeherculano 3y ago
Random question: what font did you use to make that Konilo logo? It's gorgeous.
- millsteed 3y ago
  I think it’s Adorn Roman by Laura Worthington.
  - crc_ 3y ago
    This is correct.
ilaksh 3y ago
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.
- alexisread 3y ago
  You might want to take a look at forthstation which runs on an esp32 and outputs to vga. It's relatively simple to switch to SPI lcds as the underlying esp32forth compiles under the arduino ide https://esp32forth.forth2020.org/projects-10 https://esp32forth.forth2020.org/projects-10
- crc_ 3y ago
  There is some limited graphics support. The underlying system (ilo) has a branch for x11 providing a limited framebuffer and pointing device support, and the native x86 system optionally supports a low resolution display (but no mouse yet). My son & I are working on expanding the graphics functionality, though we aren't expecting to have this work finished until later this year.
frompdx 3y ago
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.
- MaxBarraclough 3y ago
  > Direct threaded code. Faster execution compared to traditional indirect threaded Forth. Maybe, it depends on the hardware. An old comment of mine on this topic: https://news.ycombinator.com/item?id=29534435 https://news.ycombinator.com/item?id=29534435
whartung 3y ago
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.
tombert 3y ago
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?
- deleted 3y ago
  [deleted]
- smackeyacky 3y ago
  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 3y ago
    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.
    - 3y ago
7thaccount 3y ago
How does one use this without an operating system?
- crc_ 3y ago
  There is a version that runs natively on x86 hardware (through it's a 32-bit system, aimed at older hardware; my newest x86 hardware is over a decade old and I've not had time to work much on a 64-bit system & drivers). See konilo.org/x86
  - 7thaccount 3y ago
    Yeah, but how do I get that running on an old x86? Boot from a floppy somehow?
    - crc_ 3y ago
      There is a floppy image on the x86 page. I also have multiboot compatible kernels linked there for use with GRUB or similar bootloaders.
anthk 3y ago
Uhm, would the Ilo computer in C work under this 4MHZ Minix 2? https://www.homebrewcpu.com/index.htm https://www.homebrewcpu.com/index.htm
- crc_ 3y ago
  ilo could likely be made to work, though with some limitations. From a quick reading of the linked system: - ilo is little endian (for block & rom format); if you wanted to keep external compatibility, this would need to be dealt with. It's not difficult to do this; e.g., the 68k Mac version does this: fossils.retroforth.org:8000/ilo/file?name=vm/ilo-68k-mac.c&ci=tip - this system presents some memory limits that would necessitate changes to ilo. Two aspects stand out to me. First, separate code & data sections, with a limit of 64K each. ilo's standard memory area is a flat 65,536 32-bit words, needing 256K. This can be reduced, but will then not work with a standard Konilo rom. (The memory layout in the Konilo rom can be edited by modifying the assembly, but the overall reduction in available space will be very limiting for a full Konilo system. It'd be fine for using just the basic wordset in the rom or for assembly programs). Second, memory is divided into 2K banks, so a bit of work in ilo may be needed to deal with that. The previously linked Mac version can deal with this as well. - performance will be slow. ilo is internally a 32-bit system. I've built & run it on an old 8088 MS-DOS system, but it's very slow there. I suspect it'd also be quite slow here as this is another 16-bit system. I don't have the timings for this, but starting up a minimal Konilo system on an emulated Mac Plus (mini vMac @ 1x, emulating an 8MHz 68k CPU) takes 1m8s. It took quite a bit longer to start up on the DOS system. Though again, this is when running Konilo. It'll be much faster with smaller assembly programs or things that do less i/o.
geon 3y ago
What's up with the aversion to filesystems in forth languages?
- crc_ 3y ago
  Filesystems introduce complexity that may not be needed, especially on smaller targets. I'm personally not averse to file systems. I've implemented (but not yet published) a couple for testing purposes. It's probable that one or more of these will eventually be included in Konilo. But that won't happen until I write a program that needs this and have an implementation that I'm happy with.
- throwaway81523 3y ago
  That was more of a thing in earlier days (before my time) when Forth typically ran on the bare hardware, replacing the OS. Later, blocks vs files became a big debate in the Forth world, but with Forth now usually hosted under a conventional OS, files have mostly won out except among some die hards. The ROM code for the Green Arrays processor though is still written using blocks. You can download it as a nicely formatted HTML file from greenarrays.com. Here's a Usenet post from 2003 that discusses blocks: The central thing Forth depends on is KISS. We've consistently rejected complicated solutions when simpler solutions work. The result is fewer co-adaptations, where you can't change one thing because it's built into a bunch of other things. We do have some of that but not very many. Giving up blocks removed a lot of them. Blocks gave an integrated editor, and fast integrated compiling, and a sort of paged virtual memory, and something you could easily turn into a somewhat inferior database, etc. It wasn't the best solution for very much but it gave an easy adequate solution for a whole lot. I read that using blocks was a fundamental cause of the Valdocs failure so many years ago. They started out with blocks and then ran into limits and instead of throwing them out and starting over they tried to design around them and ran out of time. Now we use blocks when the problem demands them instead of wherever they look good enough. It takes longer and we probably get better solutions. -- Jonah Thomas, [[https://groups.google.com/d/msg/comp.lang.forth/7gWtjMoQXk8/Wr0yBdbZMWsJ][comp.lang.forth 2003-07-18]]
ngcc_hk 3y ago
Not the intended audience I guess. I wonder whether one can use this to learn Forth. The free-to-evaulate Forth SwiftForth has a Starting Forth book. Can there be something like a tutorial like that. Those comments does not run here (and SwiftForth is 32 bit not running on my Mac Arm BookAir 15. e.g. if you try https://www.forth.com/starting-forth/11-forth-compiler-defining-words/ https://www.forth.com/starting-forth/11-forth-compiler-defin... ``` (: VARIABLE ( -- ) CREATE 0 , ; word not found: VARIABLE word not found: -- word not found: CREATE word not found: , ) ``` This is not ANSI Forth? And one cannot just start to use like any Forth?
- crc_ 3y ago
  Konilo is not an ANSI Forth. It's a unique dialect with similarities to my older RetroForth system, which is also not a traditional model. In Konilo, that example would look like: :variable d:create #0 comma ; and using it would appear as: 'ORANGES variable While much of the system is complete, documentation has been lacking, partly due to me not investing much time on this while things were evolving. Now that it's stable, I am working on this, and have added some information to the manual (see https://konilo.org/manual https://konilo.org/manual) to help clarify that it's not a traditional Forth model.
  - ngcc_hk 3y ago
    Thanks. It is great as I can run under my ipad both pythoista and ish even. But changing the basic syntax will be hard for beginner. May I suggest have some tutorial. In particular for both external (say vim or any external shell script) and internal (hoe to use any editor and save the current work in progress) use. I found it hard even to navigate under your hypertext, sorry …
    - crc_ 3y ago
      Thank you for the feedback. I'm hoping to have the documentation considerably improved over the remainder of the year. Apart from the current work on the hypertext manual, a larger book format manual and tutorial are being worked on, though they're both very incomplete at present. On the internal/external bits, Konilo is largely intended to be a self contained environment, but it is possible to use in some contexts with outside tools. I'll write up something on this in the next few days and will post a reply in this thread with a link once it's done.

187 points by marttt 3y ago

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 3y ago
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.
- ithkuil 3y ago
  Kaposmegulo!

mark_l_watson 3y ago

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 3y ago
Did you eventually run across GraFORTH by fellow HN'er lutusp? https://archive.org/details/a2_GraFORTH_1981_Lutus_Paul https://archive.org/details/a2_GraFORTH_1981_Lutus_Paul
- mikewarot 3y ago
  I remember typing in program into GraFORTH on my friend's Apple ][ as he read it to me. The resulting animation of the earth and the space shuttle opening its cargo doors was amazing back then. I'll never forget it.
- mark_l_watson 3y ago
  Good question, but I don’t remember.

alexisread 3y ago

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 3y ago
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 3y ago
  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 3y ago
    > 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.

packetlost 3y ago

This reminds me of the Uxn from 100r. I'm always happy to see more FORTH-ish languages on my feed

z5h 3y ago
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 3y ago

Neat name. It’s probably just a coincidence, but “konilo” means “knowing machine” in Esperanto.

vitiral 3y ago
I highly doubt that is a coincidence

filipeherculano 3y ago

Random question: what font did you use to make that Konilo logo? It's gorgeous.

millsteed 3y ago
I think it’s Adorn Roman by Laura Worthington.
- crc_ 3y ago
  This is correct.

ilaksh 3y ago

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.

alexisread 3y ago
You might want to take a look at forthstation which runs on an esp32 and outputs to vga. It's relatively simple to switch to SPI lcds as the underlying esp32forth compiles under the arduino ide https://esp32forth.forth2020.org/projects-10 https://esp32forth.forth2020.org/projects-10
crc_ 3y ago
There is some limited graphics support. The underlying system (ilo) has a branch for x11 providing a limited framebuffer and pointing device support, and the native x86 system optionally supports a low resolution display (but no mouse yet). My son & I are working on expanding the graphics functionality, though we aren't expecting to have this work finished until later this year.

frompdx 3y ago

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.

MaxBarraclough 3y ago
> Direct threaded code. Faster execution compared to traditional indirect threaded Forth. Maybe, it depends on the hardware. An old comment of mine on this topic: https://news.ycombinator.com/item?id=29534435 https://news.ycombinator.com/item?id=29534435

whartung 3y ago

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.

tombert 3y ago

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?

deleted 3y ago
[deleted]
smackeyacky 3y ago
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 3y ago
  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.
  - 3y ago

7thaccount 3y ago

How does one use this without an operating system?

crc_ 3y ago
There is a version that runs natively on x86 hardware (through it's a 32-bit system, aimed at older hardware; my newest x86 hardware is over a decade old and I've not had time to work much on a 64-bit system & drivers). See konilo.org/x86
- 7thaccount 3y ago
  Yeah, but how do I get that running on an old x86? Boot from a floppy somehow?
  - crc_ 3y ago
    There is a floppy image on the x86 page. I also have multiboot compatible kernels linked there for use with GRUB or similar bootloaders.

anthk 3y ago

Uhm, would the Ilo computer in C work under this 4MHZ Minix 2? https://www.homebrewcpu.com/index.htm https://www.homebrewcpu.com/index.htm

crc_ 3y ago
ilo could likely be made to work, though with some limitations. From a quick reading of the linked system: - ilo is little endian (for block & rom format); if you wanted to keep external compatibility, this would need to be dealt with. It's not difficult to do this; e.g., the 68k Mac version does this: fossils.retroforth.org:8000/ilo/file?name=vm/ilo-68k-mac.c&ci=tip - this system presents some memory limits that would necessitate changes to ilo. Two aspects stand out to me. First, separate code & data sections, with a limit of 64K each. ilo's standard memory area is a flat 65,536 32-bit words, needing 256K. This can be reduced, but will then not work with a standard Konilo rom. (The memory layout in the Konilo rom can be edited by modifying the assembly, but the overall reduction in available space will be very limiting for a full Konilo system. It'd be fine for using just the basic wordset in the rom or for assembly programs). Second, memory is divided into 2K banks, so a bit of work in ilo may be needed to deal with that. The previously linked Mac version can deal with this as well. - performance will be slow. ilo is internally a 32-bit system. I've built & run it on an old 8088 MS-DOS system, but it's very slow there. I suspect it'd also be quite slow here as this is another 16-bit system. I don't have the timings for this, but starting up a minimal Konilo system on an emulated Mac Plus (mini vMac @ 1x, emulating an 8MHz 68k CPU) takes 1m8s. It took quite a bit longer to start up on the DOS system. Though again, this is when running Konilo. It'll be much faster with smaller assembly programs or things that do less i/o.

geon 3y ago

What's up with the aversion to filesystems in forth languages?

crc_ 3y ago
Filesystems introduce complexity that may not be needed, especially on smaller targets. I'm personally not averse to file systems. I've implemented (but not yet published) a couple for testing purposes. It's probable that one or more of these will eventually be included in Konilo. But that won't happen until I write a program that needs this and have an implementation that I'm happy with.
throwaway81523 3y ago
That was more of a thing in earlier days (before my time) when Forth typically ran on the bare hardware, replacing the OS. Later, blocks vs files became a big debate in the Forth world, but with Forth now usually hosted under a conventional OS, files have mostly won out except among some die hards. The ROM code for the Green Arrays processor though is still written using blocks. You can download it as a nicely formatted HTML file from greenarrays.com. Here's a Usenet post from 2003 that discusses blocks: The central thing Forth depends on is KISS. We've consistently rejected complicated solutions when simpler solutions work. The result is fewer co-adaptations, where you can't change one thing because it's built into a bunch of other things. We do have some of that but not very many. Giving up blocks removed a lot of them. Blocks gave an integrated editor, and fast integrated compiling, and a sort of paged virtual memory, and something you could easily turn into a somewhat inferior database, etc. It wasn't the best solution for very much but it gave an easy adequate solution for a whole lot. I read that using blocks was a fundamental cause of the Valdocs failure so many years ago. They started out with blocks and then ran into limits and instead of throwing them out and starting over they tried to design around them and ran out of time. Now we use blocks when the problem demands them instead of wherever they look good enough. It takes longer and we probably get better solutions. -- Jonah Thomas, [[https://groups.google.com/d/msg/comp.lang.forth/7gWtjMoQXk8/Wr0yBdbZMWsJ][comp.lang.forth 2003-07-18]]

ngcc_hk 3y ago

Not the intended audience I guess. I wonder whether one can use this to learn Forth. The free-to-evaulate Forth SwiftForth has a Starting Forth book. Can there be something like a tutorial like that. Those comments does not run here (and SwiftForth is 32 bit not running on my Mac Arm BookAir 15. e.g. if you try https://www.forth.com/starting-forth/11-forth-compiler-defining-words/ https://www.forth.com/starting-forth/11-forth-compiler-defin... ``` (: VARIABLE ( -- ) CREATE 0 , ; word not found: VARIABLE word not found: -- word not found: CREATE word not found: , ) ``` This is not ANSI Forth? And one cannot just start to use like any Forth?

crc_ 3y ago
Konilo is not an ANSI Forth. It's a unique dialect with similarities to my older RetroForth system, which is also not a traditional model. In Konilo, that example would look like: :variable d:create #0 comma ; and using it would appear as: 'ORANGES variable While much of the system is complete, documentation has been lacking, partly due to me not investing much time on this while things were evolving. Now that it's stable, I am working on this, and have added some information to the manual (see https://konilo.org/manual https://konilo.org/manual) to help clarify that it's not a traditional Forth model.
- ngcc_hk 3y ago
  Thanks. It is great as I can run under my ipad both pythoista and ish even. But changing the basic syntax will be hard for beginner. May I suggest have some tutorial. In particular for both external (say vim or any external shell script) and internal (hoe to use any editor and save the current work in progress) use. I found it hard even to navigate under your hypertext, sorry …
  - crc_ 3y ago
    Thank you for the feedback. I'm hoping to have the documentation considerably improved over the remainder of the year. Apart from the current work on the hypertext manual, a larger book format manual and tutorial are being worked on, though they're both very incomplete at present. On the internal/external bits, Konilo is largely intended to be a self contained environment, but it is possible to use in some contexts with outside tools. I'll write up something on this in the next few days and will post a reply in this thread with a link once it's done.