weixin_39569753
weixin_39569753
2021-01-10 19:09

Collapse OS in Forth

Please see this: http://www.camelforth.com/page.php?5

Forth is one of my past loves. It can be used for most things rather well and is the precursor to PostScript found in printers. Using Forth one could conceivably construct a Display PostScript like system to build a rudimentary GUI system, and provide print support.

Any chance of including a version of CamelForth with CollapseOS? I'd like to hear your thoughts.

Cheers, and great work on this project!

G.

该提问来源于开源项目:hsoft/collapseos

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

100条回答

  • weixin_39874196 weixin_39874196 4月前

    It's more simpler yo implement something like ed or sed, but that would require stdio, that i'm not sure if we have It (but desirable anyway).

    点赞 评论 复制链接分享
  • weixin_39665847 weixin_39665847 4月前

    , I read this story about screen size and block size somewhere long time ago. Although it is not mentionned by Mr Moore himself , I never questionned it. Thanks!

    点赞 评论 复制链接分享
  • weixin_39874196 weixin_39874196 4月前

    I love filesystems, so I can give some clues here :-D

    FAT12/16 would be ok for the constrains of the system and at the same time provide some compatibility, but has some ugly design decisions regarding metadata (FAT itself is shity compared to inodes, but is really simple to implement and understand). If you are interested on compatibility, I would go directly to ExFAT since it's similar in concept to FAT but is not backwards compatible so have removed a lot of cruft, and not only it's more alike to modern standards (it's more like a FAT32 using 64bits and without MS-DOS legacy features) and it's totally future-proof.

    Other thing as said before, could be to provide first access to blocks and implement a "RawFS" with no directories and where each file is named with the block number to start with, and later design a filesystem that better fit the constraints of the system and without the limitations of FAT, like execution bit and permissions and these things.

    点赞 评论 复制链接分享
  • weixin_39637386 weixin_39637386 4月前

    The BLOCKS management looks an obvious choice for forth. Having it will potentially make your forth compatible with other existing forth sources.

    Since filesystems for forth will likely be very modular (eg, you just have to redefine some IO words to load from storage instead of terminal) I would start small and grow.

    First implement 1024 bytes blocks over raw EEPROM Then implement the good old FAT that works everywhere, so you can potentially load disks and other storage devices. Then you can implement blocks storage in FAT (just have 1KB files with numerical names) And then you can implement loading of arbitrary files.

    Something like that...

    点赞 评论 复制链接分享
  • weixin_39874196 weixin_39874196 4月前

    First implement 1024 bytes blocks over raw EEPROM Then implement the good old FAT that works everywhere, so you can potentially load disks and other storage devices. Then you can implement blocks storage in FAT (just have 1KB files with numerical names) And then you can implement loading of arbitrary files.

    Should 2 and 3 be swapped?

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    Basic disk block support with LIST and LOAD implemented. I've moved documentation to in-system filesystem.

    I'm rather pleased at how simple nested LOAD support was to implement. zasm doesn't support nested includes because it would incur a very big complexity cost, but with Forth, that nested load support was only a matter of playing with RSP a little bit.

    点赞 评论 复制链接分享
  • weixin_39548805 weixin_39548805 4月前

    Another Forth resource: Forth on the 6502 forum. It's a good place to ask questions and evangelize the project.

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    Things continue to get more interesting and the path to self-hosting is becoming clearer. As you can see in d466c6d, I could remove forth/z80a.fs now that the stage 2 bootrapper uses the one from blk/.

    Shortly, the whole project is going to be in those blk/. Of course, it's a bit ugly from the vantage point of a modern environment, but "pretty-from-POSIX-env" isn't part of the design goals.

    Soon, it will become more convenient to work on Collapse OS from within it than from outside it. That will be a significant milestone. I'll continue development from my TRS-80 4P, just for the kicks :)

    点赞 评论 复制链接分享
  • weixin_39874196 weixin_39874196 4月前

    Shortly, the whole project is going to be in those blk/.

    What's the purposse of blk/?

    Of course, it's a bit ugly from the vantage point of a modern environment, but "pretty-from-POSIX-env" isn't part of the design goals.

    I don't find it necesarily bad, it's good to have a POSIX-like environment, but it's better to have an environment that better fits the needs. There are some things in POSIX that find them very limitating, like file access permissions and modes, and always it's possible to create a POSIX-like layer on top of it... This is one of the blames I have with ReduxOS. Anyway, picking some concepts or ideas from POSIX is not bad, too :-)

    Soon, it will become more convenient to work on Collapse OS from within it than from outside it.

    I would not deprecate the hability to develop CollapseOS from a regular desktop... Maybe add desktop PCs as another target device like Project Catalyst (iOS APIs on macOS) does with macOS regarding iOS development?

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    blk/ is the block-based filesystem. Its purpose is to be accessible and workable from within Collapse OS. For more information, run Collapse OS from the emulator and run 0 LIST.

    点赞 评论 复制链接分享
  • weixin_39687189 weixin_39687189 4月前

    This forth implementation is interesting. https://github.com/asrp/flpc

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    It doesn't seem very compact.

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    I hadn't tested the rc2014/sdcard recipe on real hardware until now, but it's a homerun! Having it work on the emulator was sufficient, no adjustment is necessary for it to work on a real SD card (at least on the SD card I use for testing...).

    点赞 评论 复制链接分享
  • weixin_39625872 weixin_39625872 4月前

    Please have a look at https://www.complang.tuwien.ac.at/forth/vibe-2.1ans.fs I think it's a very compact vi-like editor that could inspire the current block editor of CollapseOS. WDYT? Great work by the way 👍

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    it looks interesting, but it depends on AT-XY, something that not all systems have (if you're on a serial console, you don't have it unless you build a curses-like library). My first plan is to implement the editor described in Starting Forth, and then a more visual one for systems having access to a grid-like video subsystem.

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    It now runs on the RC2014 through the Serial I/O module (that is, the Forth-based ACIA driver is functional and we have a first real-word example of Collapse OS' Forth cross-compiling itself)

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    if you ever try to venture into compiled dictionary relinking (like I tried in forth/link.fs), I should warn you it's a dead end. It's impossible to reliably relink a compiled dict in a ITC execution model.

    The challenge stays the same: how to compile a dict that is going to end up in a ROM and that, in RAM at a different memory offset than its final destination?

    I'm backtracking and my next attempt will be a memory mapping system. Add an indirection at the @/C@/!/C! level and allow dynamic mapping. This way, I could, for example, map the area of the ROM following the bootstrap binary to somewhere in RAM and compile my dict as if I was directly in ROM.

    Should work...

    点赞 评论 复制链接分享
  • weixin_39637386 weixin_39637386 4月前

    Okay, thanks for the info. My progress is desperately slow (no time for coding personal projects right now) I am now developing the required words for my own forth. Goal is still minimal amount of asm code even if its slow. I still hope to have a position independent precompiled dictionary somehow, I'm sure I'll find a way.

    点赞 评论 复制链接分享
  • weixin_39874196 weixin_39874196 4月前

    Goal is still minimal amount of asm code even if its slow.

    I agree on that, the bare minimum quantity of assemble glue code (ports and memory access), and try to do almost all in Forth or any other high level language (including drivers). There will be time to do platform-specific optimized versions later...

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    for the system to be self-hosting, it also requires that this Forth implementation can cross-compile itself, which is what I'm trying to achieve.

    BTW, memory mapping is also a dead end...

    点赞 评论 复制链接分享
  • weixin_39665847 weixin_39665847 4月前

    "BTW, memory mapping is also a dead end..."

    Look at M. Ting implementation of eForth for stm32 discovery board. He use system variables to locate dictionary and other components. I don't know if it could be of any use in that case. There is a pdf describing the system. https://github.com/wa1tnr/eforth-stm32f4x-a/tree/master/0-Distribution.d/eForth

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    It's an interesting read indeed. I'm unfamiliar with STM32F4, but it seems that it has memory mapping capabilities, which makes cross compiling much easier. Magic seems to happen at section 3.2.3 of the PDF.

    With the z80, I don't have this kind of mechanism.

    点赞 评论 复制链接分享
  • weixin_39874196 weixin_39874196 4月前

    With the z80, I don't have this kind of mechanism.

    It could with an external MMU, but that would add complexity to the project so it's outside of context. By other side, some docs or driver for memory banking would be nice have, too... :-)

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    Success! With memory mapping being a dead and and high-level xcomp not being able to successfully cross compile hairy stuff like DOES> words, I've backtracked on my earlier backtracking and revisited the link.fs approach, but this time by adding an "address" literal. It works.

    The RC2014 recipe now contains instructions to get to a stage2 binary from within a RC2014!

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    Now that AT28 EEPROM writing support is implemented and functional for the RC2014, I'm at the point where I need to consider implementing a filesystem, so I was asking myself questions. Do I reimplement CFS? Since we have a high level language, why not aim for FAT?

    But then I re-read the section about Forth's file disk block system in Starting FORTH, which I had skipped earlier because it seemed too limiting. But now I'm hesitating. Is it really? There's something very appealing to this primal simplicity.

    ... so yeah, Collapse OS's new FS will probably be 1024 bytes blocks. maybe add something like "every 256th block is filled with CRC-32 of previous blocks" or something like that. And a convention like "every first X blocks are textual description of the contents of the following block numbers". Might work. Very simple. Appealing.

    点赞 评论 复制链接分享
  • weixin_39665847 weixin_39665847 4月前

    At this point maybe you should read how Chuck Moore implemented such 1024 bytes block file system. But don't get stuck with that format. 1024 block was so because at the time Mr Moore was using a terminal with 1024 characters screen and he was saving text screen as is. Consider that FAT system is not that complex to implement. Look at MS-DOS 1.25 source code now available as open source at https://github.com/microsoft/MS-DOS

    To read Mr Moore: https://library.nrao.edu/public/memos/comp/CDIR_11.pdf, Chapter 9 is of concern here.

    点赞 评论 复制链接分享
  • weixin_39665847 weixin_39665847 4月前

    If you prefer to look at a FAT file system in C look at https://github.com/lucianbrandabur/Arduino-Reef/tree/master/libraries/tinyFAT

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    1024 block was so because at the time Mr Moore was using a terminal with 1024 characters screen and he was saving text screen as is.

    Yes, I understand the historical context. However, Collapse OS target machines that don't exist yet and most of them might have similar constraints. Therefore, designing Collapse OS around old-school constraints might not be so short-sighted after all.

    Thanks for the PDF link, I hadn't read that one yet. Seems interesting.

    点赞 评论 复制链接分享
  • weixin_39637646 weixin_39637646 4月前

    Jackes 1024 as block was choosen because 2 to the power of 10 divides the adress space in exact equal chuncks of physical memory. Physical memory is the memory space which CPU address lines can seek directly, not much to do with monitors !

    Forth calls the 1024 memory space as a BLOCK , and a SCREEN is represented 64bytesx16 rows on a text monitor. A Screen could have been any other number, since monitors had 80 rows very early. So he choosed the 1K Screen only to simplify things. The first computer where Charles implemented Forth was programmed on punched cards, which had --1K blocks of code -- ! and a teletype writer he had no monitor at all !

    I love screens, and all the phylosophy of programming in small spaces , triying to code WORD definitions of only 1 or 2 rows, this Block/Screen system makes the programmer very productive.

    I don´t think FAT32 can be so appealing ! Using RAW blocks is much more, and also can teach new programmers a lot of techniques that we use in the Forth world with great success.

    For this reasons 1K blocks are much more close to the metal, than a Fat system, that exists only as a convention, but has any hardware correlation, as blocks have. IMO blocks file systems help programmers understant to the deepest level the machine without effort. If you are talking to magnetic medium, and if you have a stepper floppy disk, yoiu will be able to see the head go exactly where you want only by a number 10 BLOCK or ... 150 BLOCK... how cool is that ? (BTW I progammed my own block system in 1985 using a WD1772 chip, on a 68K computer, but I wanted a "raw" block forth running on it, and it was lots of fun. I could implement all what I was reading on the Data book of the WD1772, using the same words... this is where Forth really shines). Shadow Blocks is another spectacular way to comment code. And if you have a BLOCK file system running, in no more than 2 SCREENS = 2K high level forth words you can implement a FAT system OVER it without problems.

    On Mon, Apr 13, 2020 at 5:42 PM Jacques wrote:

    At this point maybe you should read how Chuck Moore implemented such 1024 bytes block file system. But don't get stuck with that format. 1024 block was so because at the time Mr Moore was using a terminal with 1024 characters screen and he was saving text screen as is. Consider that FAT system is not that complex to implement. Look at MS-DOS 1.25 source code now available as open source at https://github.com/microsoft/MS-DOS

    To read Mr Moore: https://library.nrao.edu/public/memos/comp/CDIR_11.pdf, Chapter 9 is of concern here.

    — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hsoft/collapseos/issues/4#issuecomment-613087949, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKLYKHWAWTXDVDLLXQJDPJ3RMN2KVANCNFSM4I6UHPSA .

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    I don't use any existing implementation as an inspiration because I have troubles understanding them fully. I'm missing comprehension keys which I feel I can only acquire by implementing a Forth myself.

    That eForth overview is interesting, thanks. My current implementation is trending toward assembly simplification. To have something that worked as quick as possible, I leveraged existing assembly code in Collapse OS, but much of that code can be implemented in Forth. it's just a matter of making it "bubble up".

    You can see, for example, what I did with (parsec), (parseb), (parseh). That was bubbling up.

    I'm in the process of doing the same thing with the readline routine.

    (also, I don't think I'll want to go as far as eforth in the minimisation of the assembly code. For example, arithmetic routines: even if portability is a goal, implementing +-*/ in assembler is far from being such a difficult task and their presence doesn't require us to have a more complex assembler program. Therefore, I'd tend to keep them native)

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    Things are getting really exciting, I've just pushed the CODE word, which allows such interactions in the interpreter:

    
    $ ./forth/forth
    > CODE foo
    > HL POPqq,
    > HL INCss,
    > HL PUSHqq,
    > JPNEXT,
    > 42 foo .
    43
    >
    

    This means that I can start "bubbling up" native words (stack mgmt and arithmetic are the first ones that come to mind) to Forth, paving the way for full Forth self-hosting!

    点赞 评论 复制链接分享
  • weixin_39637386 weixin_39637386 4月前

    the CODE word allows a word definition to be made of assembled native code, right?

    This is not really self hosting, but complete self bootstrap!

    I've only seen this in a Java OS, that created a binary image of minimal the VM+class libraries to be dumped in the memory and executed. This allowed a java VM to boot and load more classes.

    Reading your last commit, do I understand that you have managed to make a reusable compiled dictionary? Now the only issue for portability is the set of natively implemented words.

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    yes,you read that right, but I'm not quite at self-bootstrap yet. There are still significant roadblocks ahead (one of them being to manage the fact that word references are in absolute addresses.This doesn't play well with compiling dict and concatenating them) , but the way is paved.

    点赞 评论 复制链接分享
  • weixin_39637386 weixin_39637386 4月前

    Yes, I have identified this problem too.

    Linking of word entries can be done as offset to the previous entry. This avoids the use of explicit memory addresses to build the linked word list.

    Word references in compiled definitions could be offsets to the beginning of the dic, like if the dic address was zero. The inner interpreter (the NEXT routine) can add the actual dic load address before jumping, then the execution would be a bit slower but then the dictionary would be truly position independent, I think.

    The problem of linking the fundamental native words in this dic remains, but it could be managed if these are well positioned relative to the "dictionary blob". if the few native word entries have known, fixed, and documented sizes, they can be negative offsets. Or, the dictionary could require to be concatenated to a small jump table, still using negative offsets to reference these words, but then the implementation of these words do not matter.

    It would be good to standardize these words, and the dic format, to allow several projects reuse the same dictionary blob.

    The eForth implementation referenced before only relies on 31 native words including the usual ones like DUP et al.

    I like that the control structures in this forth are just implemented by 3 simple words: "branch" (like JMP), "0branch" (like BEQ), and "next" (like decrement and branch) words, that are just followed by a literal IP value.

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    These are, indeed the first possible solutions I've identified and I've already "relativized" previous field offsets.

    However, I'm hesitant to "relativize" every reference. It would make the whole system more sluggish and there are probably cases I haven't thought about where we execute a word reference without knowing exactly where we are (which means we can't perform the subtraction).

    My first idea is a kind of linker that could change addresses at concatenation time. But even this, I find heavy handed.

    I have the intuition that a simpler, more elegant solution is possible.

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    I think I've had a nice idea to solve the chicken-and-egg absolute address problem. You can see in recent commits that I started "bubbling up" native words. It works: further definitions in *.fs can reference them. So far, it works for two reasons:

    1. Nothing in forth.asm reference them
    2. Those words don't reference each other.

    This approach obviously has limits and I'm wondering how I'll bubble other words up, such as OVER which is used by WORD.

    The idea I had was RAM references. We know our RAMSTART at compile time. What about reserving specific offsets in RAM for word that are not in forth.asm? At initialization time, I could run find for each of those words and fill RAM with proper offsets.

    For example, let's say that I bubble up OVER, used by WORD. I reserve a space in RAM called OVERI (OVER indirect) and then replace .dw OVER, pointing to ROM with .dw OVERI, pointing to RAM.

    After that, it's a matter of adding a new fundamental word routine, something like linkWord which simply redirects to the word offset specified in PFA.

    Sounds doable...

    点赞 评论 复制链接分享
  • weixin_39637386 weixin_39637386 4月前

    I see. The RAM pointer table is a more generic solution than my negative word offsets, but it requires one additional indirection, and I am a bit fed up with indirections right now lol.

    You are clearly ahead of me terms of design and forth exploration, but I find this process quite complicated. I dont think my own project will require something as complex, but I'm not here yet.

    I just got my forth interpreter to work. It's an indirectly threaded interpreter (threading explained here https://www.bradrodriguez.com/papers/moving1.htm) in an attempt to save some memory in each definition at the expense of speed. NEXT has to do two indirections. So each word has a pointer to the assembly that allows running the word, either "enter" (to recurse in a word), "literal" (to push the next opcode on the stack), etc. I was able to use the hc11 simulator I wrote before to single-step in it with GDB, which is really helpful. Since it has no IO yet, running that in real hardware is not possible yet.

    I will now be working on the console interpreter: ACCEPT,PARSE,FIND,EXECUTE.

    I am still using eForth as an inspiration. https://github.com/f4grx/sys11/blob/master/forth/main.asm

    The assembly source is still very small, it currently assembles to a 319 bytes HC11 binary. I will rewrite later the full assembly source using a forth syntax so it can be re-assembled from forth. That is where I will probably encounter problems like yours...

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    With the "Forth-ification" of INTERPRET and ; in my last two commits, we're beginning to have serious self-bootstrapping action...

    点赞 评论 复制链接分享
  • weixin_39672572 weixin_39672572 4月前

    I'm not sure if you're aware of this, but the Jupiter Ace was a Z80 based home computer released in 1982 which used Forth instead of Basic.

    The ACE had an 8 KB ROM containing the Forth kernel and operating system, and the predefined dictionary of Forth words in about 5 KB. The remaining 3 KB of ROM supported several functionalities: floating point numbers library and character definitions table, tape recorder access, decompiling and redefining newly re-edited 'words' (i.e. routines).[17] Some of the ROM was written in Z80 machine code, but some was also coded in Forth.

    ACE's Forth was based mostly on Forth-79, with some relevant differences,[5]:176 in particular it added syntax checking to control structures and definer constructions and a few extra words were added based on common BASIC sound, video and tape commands. The implementation lacked some less frequently used Forth words, these being easily implemented if needed. Runtime error checking could be turned off to raise speed by 25% to 50%.

    There is a disassembly of the kernel here: http://www.jupiter-ace.co.uk/romlisting.html

    Additionally the machine had a simple design based on the Sinclair ZX80 and was made of discreet TTL logic chips, so it's easily reproducible today.

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    Forth now self-bootstraps! That is, it has cut its dependency on zasm and assembles its own boot binary itself (along with, of course, the rest of its dictionary). Binary size: <7K. Not bad! I haven't measured self-assembly RAM usage, but since all words are compiled in binary, I don't think it uses much RAM. I'm pretty sure this is Collapse OS' future.

    My next steps are, after a little cleanup, to create a new forth branch where I'll rebuild the recipes to use Forth (the new branch is because this step is destructive to the zasm-based project). This will mean rewriting device drivers, filesystem, etc. in Forth (with bottlenecks in assembler I guess). I'll also have to think of a way to achieve self-hosting (self-bootstrapping in an emulator is one thing, self-hosting on a RC2014 is something else...). Then documentation, then replacement of the old project.

    点赞 评论 复制链接分享
  • weixin_39637386 weixin_39637386 4月前

    Congratulations!

    点赞 评论 复制链接分享
  • weixin_39874196 weixin_39874196 4月前

    If you think Forth is the future of CollapseOS, i would create It in a new repo from scratch, lefting this one for references/historical purposses. Also, instructivos to port Forth VM to other architectures would be needed too...

    点赞 评论 复制链接分享
  • weixin_39589394 weixin_39589394 4月前

    I found a really interesting resource for understanding how forth works - "Jones Forth" and various derivatives of it. It's a wonderful example of literate programming. Just starting reading the source code which is pretty richly commented to get a bottoms-up view of how the moving parts work.

    https://github.com/phf/forth is a project which ports the original x86 implementation to the ARM.

    There's also a series of articles that appeared in some magazine years ago, "Moving Forth" which is also interesting reading - https://www.bradrodriguez.com/papers/moving1.htm

    I found Mecrisp forth for ARM Cortex M0/M1/M3 CPUs really interesting to explore. It's also ported for a number of CPU architectures and the more I read and understood the code, the more I appreciated the elegance of it. I spent a bunch of time with Mecrisp forth for the ARM as I used it in an embedded system project using a cheap "Blue Pill" STM32F103-based microprocessor. I used it to replace an old 7-segment LCD display in a Fluke voltmenter with a graphical LCD display -- it just brute-force watch the display signals and instrument button state to create an entirely new UI. Forth is a really amazing tool to interactively poke at hardware and incrementally build out an application with out the usual edit-compile-link-download-debug-profanity loop repeated over and over. https://hackaday.com/2017/04/19/moving-forth-with-mecrisp-stellaris-and-embello/ http://mecrisp.sourceforge.net/

    点赞 评论 复制链接分享
  • weixin_39712611 weixin_39712611 4月前

    GNU's gforth has a lot of documentation about the decisions to be main when implementing the main interpreter loop. Another interesting one it HP's RPL which seamlessly allows but direct and indirect threading.

    点赞 评论 复制链接分享
  • weixin_39637386 weixin_39637386 4月前

    This thread has a lot of practical information, thank you to all posters for sharing valuable resources.

    点赞 评论 复制链接分享
  • weixin_39548805 weixin_39548805 4月前

    DurexForth is a Modern Forth written for the C64. It fully supports Forth 2012 and comes with a Vi clone. I mentioned libForth earlier, I should have mentioned this too.

    Even though it's tied to the 6502, there is likely a lot that can be learned from reading the source code. Others have mentioned Starting Forth, which DurexForth's creators used extensively as a resource.

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    Wow, durexForth looks awesome!

    点赞 评论 复制链接分享
  • weixin_39637386 weixin_39637386 4月前

    Yeah.

    I think I understood the following:

    Despite being advertised as stack based, stacks are not the main storage space and can be rather small. They are just used for passing parameters between words. No idea how big it should be, but 1K looks OK, or it can just grow at the opposite side of the data space, until both meet in the middle. Only the return stack is still a mystery for me, I understand it can be much smaller than the others, but I still have to precisely visualize how it is used.

    The main data storage area is the dictionary/data space, that stores BOTH definitions for new words and allocated storage and variables in a progressively growing fashion. This means that usual program variables can just be accessed arbitrarily and data is not just stored on the stack.

    It also means that memory deallocation is not practically useful, except for the last allocated item. But we can live with that as memory is usually allocated at init time only in most systems.

    Also the CREATE/DOES> construct is still a bit of a mystery to me.

    I still have to lurk moar!

    点赞 评论 复制链接分享
  • weixin_39637386 weixin_39637386 4月前

    Thinking again, moving CollapseOS to forth means that CollapseOS itself is not a Z80 binary, but a set of Forth words usable for something else. With a Z80 assembler written in Forth, which should not be a real challenge according to the numerous existing examples, the self-hosting capability becomes so obvious that it's not a defining characteristic anymore.

    The real goal is writing a minimal forth interpreter for each supported platform. This means display/keyboard and storage drivers, and little more. Recipes would be instructions to build and load these interpreters.

    Then CollapseOS can just be a Forth Library with targeted use for Collapse Recovery: Able to cross-build a forth interpreter for other platforms and program various chips, for example... Forth is advertised as very useful for this kind of tasks.

    I'm not here to tell you what COS should be. It's just an idea that crosses my mind right now, while I am reading this: https://www.forth.com/resources/forth-programming-language/#chm

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    pretty much, yes. However, I notice that even though most Forth implementation feature assemblers, I don't see many that are self-hosting. CamelForth requires external tools to build, durexForth requires ACME suite.

    Therefore, Collapse OS' Forth, by aiming first and foremost to be self-hosting, will be a bit special among Forth implementations, yes.

    ADDENDUM: compact self-hosting will be achieved by limiting the usage of special features in the assembly language. For example, if you look at durexFoth's assembly part, it uses the features of a fully featured assembler. That makes self-hosting harder. Collapse OS' Forth will be built differently.

    点赞 评论 复制链接分享
  • weixin_39637386 weixin_39637386 4月前

    yeah I guess the assembler used for bootstrap has to be minimal, too. This is consistent with forth philosophy of avoiding to plan for the unneeded.

    Still reading docs here. I now understand the return stack. Actually the parameter stack can be limited in size, but the return stack depth is what allows complex programs to be built.

    点赞 评论 复制链接分享
  • weixin_39637386 weixin_39637386 4月前

    This page has lots of implementations, including the eForth implementations that seem to include lots of word definition in forth itself for improved portability. Looks like the native core is quite small and could be used for bootstrap. http://www.forth.org/eforth.html Particularly this hc11 version: https://github.com/tonypdmtr/eForth/blob/master/hc11e4th.asm I'll use parts of this in a way that fit my needs.

    点赞 评论 复制链接分享
  • weixin_39637646 weixin_39637646 4月前

    I don't see many that are self-hosting. However, I notice that even though most Forth implementation feature assemblers, I don't see >many that are self-hosting. CamelForth requires external tools to build, durexForth requires ACME >suite.

    hsoft: I think you are mistaken, you will always need external tools or a binary to startup your system no matter in which language you write it. Except you burn an eprom by hand typing a hex listing on the keyboard (as we did in the early of 1980). Or you have a monitor program on Rom, and download a file over serial. As we did on the development boards. There are no magic alternatives to boot without binaries !

    I would like to help you clarify, if possible, but the development of Collapse OS, vs a Camelforth, or a TRS80 forth, is not clear for me.

    You describe some features you want for Collapse Os, that forth F83 from Laxen&Perry already had 37 years ago, but you explain that "Collapse OS will be different." Probably you have not understood what forth does and how, using which tools. (metacompilation, crosscompiliation, and forths assemblers). Of course I am not blaming you, is difficult to brake this thing appart and understand the mechanics. There are too many new concepts you need to understand, the only way is with practice and implementation.

    Which platform are you using for development now, a soft simulator or a real Z80/6809 machine ? Is it a COCO ? TRS80 ? HP ?

    f4grx: eforths are completly different things "e" means easy, and are ok for teaching and very basic forth learning , since they compile tokens as bytes, they are real low performance.

    点赞 评论 复制链接分享
  • weixin_39637386 weixin_39637386 4月前

    Thanks for the information. Of course I have very little context about forth, and I am only discovering it piecewise by reading the web, and it is impossible to read everything that was written about forth since the sixties.

    The advantage of the eforth for HC11 that I am currenty reading is that it is easily readable. It seems direct threaded and using 16-bit word addresses, not byte tokens. Mine will be similar, maybe indirect threaded if more compact, but only implementation will tell.

    Byte tokens with known values MIGHT still be interesting to build a forth word library appended verbatim to a small native kernel: the smaller the kernel, the easier it is to selfhost.

    It is of course possible to build a ready-to-burn ROM image from a forth assembler. The assembler output could be redirected to burn an EPROM / write some flash / send to serial or whatever instead of writing in the data space. It is also possible to burn one using external hardware that we plan to build for these collapse recovery projects. The eeprom programmer software could be, well, written in forth of course.

    I believe the value of CollapseOS and like will be in device drivers and the support for various existing hardware (platforms and peripherals), like the already working TI83 calculators and others.

    Because yes, the goal of collapseOS (If I understood correctly) is to have working computers ready for the "apocalypse". When that happens, the remaining working computers we prepared will be used to program other ones. So this definitely need communication lines and programming hardware. The goal is to have some bootstrap platforms that can run code for restarting a full computing environment on more machines.

    it is interesting that forth can work on the arduino and bluepill and any other computing platform. These are very common and could be valuable to bootstrap more machines. But that means we have cross compilers for AVR and ARM. Forth is perfect for that. An Arduino can be programmed by SPI (available on the HC11), an ARM requires SWD (could be bitbanged on IO ports). The GoodFET has a MSP430 and can emulate many protocols, this is also a near perfect target for forth.

    Context: I am not a member of collapseOS, but I am trying to do a similar project with a 68HC11 instead of a Z80. Still, I am talking a lot on these pages because I see common interests and possibly convergence on some points.

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    Collapse OS is self-hosting. You can compile itself from within itself with no external tools

    Of course, you always need a starting Collapse OS binary to begin the process (in this project, it is at emul/zasm/zasm.bin ), but you can produce that binary from within Collapse OS itself.

    That is what I mean by self-hosting. CamelForth is not self-hosting, durexForth is not self-hosting. Their asm listing require external tools to compile their boot binaries.

    Also, to be clear, by "it will be special", I don't mean that I will be pioneering self-hosting in Forth. I'm pretty sure I'm not. However, because the Forth system I've seen so far are not self-hosting, I deduce that "self-hosting" is not a common attribute in Forth implementations. Therefore, it's going to place Collapse OS' Forth in a special category.

    点赞 评论 复制链接分享
  • weixin_39637386 weixin_39637386 4月前

    : I am reading your last commits and I see the huge progress, very nice! What forth implementation did you use as inspiration?

    I am reading through eforth implementation description and notes, and this looks simpler that yours. http://www.exemark.com/FORTH/eForthOverviewv5.pdf

    点赞 评论 复制链接分享
  • weixin_39637646 weixin_39637646 4月前

    Guys

    we have a very collaborative forth group, with professional forthers and developing a Forth for PC we call it FORTH2020 (*). A strong platform to crosscompile Forth to other processors as well.

    Forth needs a common denominator, the larger this platform becomes easier is to write compatible programs, that everybody can use , learn, interchange etc.

    Forth2020/Forthwin started as a forth on windows, but we run it on Linux too, on my PC I actually run it on Kubuntu without any problems. Is very easy to install since is only to download 1 folder and you got it running. All sources are there. We have videos , lots of documentation, etc. (We have also a native Linux distro, but are more focused in 1 platform at a time, the good point : it is 100% compatible one to the other)

    I invite you to participate, the meeting point is over FB because we can exchange videos, pictures manuals, souces, and lots of things very fast. https://www.facebook.com/groups/2225595150855239/

    Collapseos is invited to present this project in our group, and also start a crosscompiler development from Forth2020/ForthWin to your present target ! The advantage to reunite more users and get experienced programmers to give assistance or directions.

    Please don´t use trolling faking profiles, use this community for serious Forth interchange, help develop conscious programming, and divulgate the Forth language with its outstanding techniques. To join our group, we ask for a short presentation, and a first post. And to be polite and friendly to all people. Friendlyness is the basis of every community !

    We will be delighted to have CollapseOS friends evolving within our proyect too.

    Here you can assist to some interesting videos of what we can do with Forth2020. https://www.youtube.com/channel/UCVuRfCHyr0Kie7zoVJryKqA

    Cheers Peter

    On Thu, Mar 12, 2020 at 9:58 AM Philippe Brochard wrote:

    Hello. Just a feedback from a Forth enthusiast: the path this project is taking is super interesting!

    — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hsoft/collapseos/issues/4#issuecomment-598170873, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKLYKHX7IE5W7M7DBYMDDQLRHDL6XANCNFSM4I6UHPSA .

    点赞 评论 复制链接分享
  • weixin_39960147 weixin_39960147 4月前

    the book is a legend about how real computing is done, still years ahead in concepts and simplicity.

    On Thu, Mar 12, 2020 at 12:42 PM f4grx wrote:

    I will be reading this books, thanks.

    For me forth is just an annoying RPN language that cant do much besides 1 2 + . , but this whole enthusiasm may be an occasion to reconsider my feelings.

    — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hsoft/collapseos/issues/4#issuecomment-598258713, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADR73T7LFGI7YRAWSMZDOQDRHD7FJANCNFSM4I6UHPSA .

    --

    "Sling and move continents, a rock at a time."

    点赞 评论 复制链接分享
  • weixin_39960147 weixin_39960147 4月前

    GREAT!

    On Thu, Mar 12, 2020 at 12:57 PM PeterForth wrote:

    Guys

    we have a very collaborative forth group, with professional forthers and developing a Forth for PC we call it FORTH2020 (*). A strong platform to crosscompile Forth to other processors as well.

    Forth needs a common denominator, the larger this platform becomes easier is to write compatible programs, that everybody can use , learn, interchange etc.

    Forth2020/Forthwin started as a forth on windows, but we run it on Linux too, on my PC I actually run it on Kubuntu without any problems. Is very easy to install since is only to download 1 folder and you got it running. All sources are there. We have videos , lots of documentation, etc. (We have also a native Linux distro, but are more focused in 1 platform at a time, the good point : it is 100% compatible one to the other)

    I invite you to participate, the meeting point is over FB because we can exchange videos, pictures manuals, souces, and lots of things very fast. https://www.facebook.com/groups/2225595150855239/

    Collapseos is invited to present this project in our group, and also start a crosscompiler development from Forth2020/ForthWin to your present target ! The advantage to reunite more users and get experienced programmers to give assistance or directions.

    Please don´t use trolling faking profiles, use this community for serious Forth interchange, help develop conscious programming, and divulgate the Forth language with its outstanding techniques. To join our group, we ask for a short presentation, and a first post. And to be polite and friendly to all people. Friendlyness is the basis of every community !

    We will be delighted to have CollapseOS friends evolving within our proyect too.

    Here you can assist to some interesting videos of what we can do with Forth2020. https://www.youtube.com/channel/UCVuRfCHyr0Kie7zoVJryKqA

    Cheers Peter

    On Thu, Mar 12, 2020 at 9:58 AM Philippe Brochard < notifications.com> wrote:

    Hello. Just a feedback from a Forth enthusiast: the path this project is taking is super interesting!

    — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hsoft/collapseos/issues/4#issuecomment-598170873, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AKLYKHX7IE5W7M7DBYMDDQLRHDL6XANCNFSM4I6UHPSA

    .

    — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hsoft/collapseos/issues/4#issuecomment-598259095, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADR73T3R5XOYVWHN2MSPCOTRHD7H7ANCNFSM4I6UHPSA .

    --

    "Sling and move continents, a rock at a time."

    点赞 评论 复制链接分享
  • weixin_39637386 weixin_39637386 4月前

    Damn, this stuff got me interested in Forth. I know I will have to write a POC interpreter to play with it. I want to see how powerful it can be. Reading through the commit history of collapseOS is particularly interesting. It looks doable on my 68hc11 too, which means that any non-native software production in Forth could be reused in my own project.

    点赞 评论 复制链接分享
  • weixin_39637386 weixin_39637386 4月前

    what documentation sources did you read to get started with forth programming and forth interpreter implementation hints?

    edit: Never mind, I found enough reading in this thread for a lifetime of reading! How have I missed the value of forth for (37-9) years?

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    I don't know how it went for other Forth enthusiasts, but for me the trigger was trying to implement it. Only then did I see its impressive ratio of structural simplicity vs power. So I guess that your POC is effectively a good idea.

    I use Starting FORTH as a reference: https://www.forth.com/starting-forth/

    点赞 评论 复制链接分享
  • weixin_39637386 weixin_39637386 4月前

    I just tried a little POC in usual C this afternoon and I am mentally stuck when trying to implement custom words in an elegant manner. In C this is hard, you have to poke in a byte array otherwise it's malloc and linked list and thats incredibly not forthesque at all.

    here is it if you are interested, 1 2 + . actually works 187 lines of C currently: https://gist.github.com/f4grx/20f58037021a6233d3e10f287504dae4

    But the real interest of forth is custom words, and that will be much more interesting to implement in assembly in the raw 16 bit memory of my 68hc11. Moreover, it will be much more fun to implement than a storage driver. I guess I'm back to sys11 while I'm waiting for my current OSHpark PCB :)

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    you might be interested in looking at the commit log of https://github.com/hsoft/collapseforth : it's also a C implementation trying to bootstrap itself into z80.

    点赞 评论 复制链接分享
  • weixin_39637386 weixin_39637386 4月前

    What does bootstrap mean in forth case? Writing a full forth interpreter in forth? How do you drop that on a new target? You need some real machine code at some point. This concept is still hard to get for me at this time.

    I am late on the forth road, for the moment I have to make sure I understand all the datastructures involved here, only the PS and dict are clear for me. I have to understand variable storage and the return stack, and some more things like string storage and some obscure words like LITTERAL, CONSTANT, IMMEDIATE, LITTERAL, etc. Also some things that should be native are actually forth, like the IN offset and the input buffer, so I have to understand all of this before playing with bootstrap.

    Documenting the absolute minimum set of words that have to be native is a first step for me, after reading a bit more.

    edit: thanks, I see your C implementation using z80 emulation, that helps a lot.

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    In "collapseforth"'s case, "bootstrap" meant making it run on z80 using only itself as a tool for self-assembly. So, we start with a C app running on modern platforms and end up with a self-assembling z80 forth.

    In Collapse OS' Forth, by "bootstrapping", I mean breaking it free from zasm's dependency: implement a z80 assembler in Forth that can assemble Forth's native code.

    点赞 评论 复制链接分享
  • weixin_39637386 weixin_39637386 4月前

    OK, so this involves writing a Z80 assembler in forth, that will spit the Z80 assembled forth interpreter, which is able to reassemble itself on the target... mental segmentation fault, lol.

    This is very interesting. Some project that were linked before include cross assemblers for multiple platforms, this could save work to support more CPUs, and also for cross support, because your z80 assembler could then run on my hc11...

    This is more awesome than awesome! Now we have interoperability between different collapse recovery hardwares!

    (the current pcb is a msp430 led clock, you bet it will be done in forth too!)

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    yes, exactly, awesome :)

    点赞 评论 复制链接分享
  • weixin_39637646 weixin_39637646 4月前

    What does bootstrap mean in forth case? Writing a full forth interpreter in forth? How do you drop that on a new target? You need some real machine code at some point. This concept is still hard to get for me at this time.

    I am late on the forth road, for the moment I have to make sure I understand all the datastructures involved here, only the PS and dict are clear for me. I have to understand variable storage and the return stack, and some more things like string storage and some obscure words like LITTERAL, CONSTANT, IMMEDIATE, LITTERAL, etc. Also some things that should be native are actually forth, like the IN offset and the input buffer, so I have to understand all of this before playing with bootstrap.

    Documenting the absolute minimum set of words that have to be native is a first step for me, after reading a bit more.

    edit: thanks, I see your C implementation using z80 emulation, that helps a lot.

    Some forths have the possibility to write in HIGH LEVEL Forth Words to a --> TARGET and that target will receive a full forth interpreter+ your words, so It will execute your HIGH LEVEL forth Words. This means, Forth can create another Forth either way for its own CPU or for another external Target with a process that is called METACOMPILATION.

    We have some examples of Metacompilers in ForthWin as also in Win32forth, and I think Brad Rodriguez(Camelforth) on his site explains also the process of Metacompilation.

    The best way to understand forth is to go after an eForth (Dr.Ting) for example, see my booksite with lots of links to Dr.Tings work, and the SVFIG listing he donated to PublicDomain last year. https://sites.google.com/view/forth-books/home/forth-books/dr-tings-collection14

    68hc11 was superb processor for Forth, we used it very much in robotics applications in the late 80´s and 90´s . It was a company dedicated exclusively to its apps.. including the CAMEL forth that was in rom. So you could buy from New Micros a board with 68HC11 and start programming on a serial terminal on Forth with it. The 68hc11 was made thinking on Forth, because it has the ";" (NEXT) word in microcode instruction inside the chip ! This permits to run very efficient threaded code.

    Metacompiler inspite to be a solution is a real nightmare, there is no need you enter into that field , before you do not understand 100% an eForth and other types of Forth.

    You can write perfectly well your primitives with a crosscompiler in Assembly, and "knit" your Forth by hand and it will run perfectly well.

    You can also use a Forth crossassembler and create your forth over another high level forth. Use an address space of your dictionary, reserved with
    CREATE COLLAPSEOS 8000 ALLOT \ ( reserve 8kbytes as memory space for my crossasembl.)

    and all your Forth crossassembler words should compile to that space COLLAPESEOS when you have some words ready to go, you can donwload ´ COLLAPSEOS ( address of Coll-OS) 8000 DUMP will show your dictionary , or you can save that space to a file, and burn that into Eprom or make a flash-ram on your cpu. I don´t know how your boards looks like and what resources you have there.

    Cheers Peter

    点赞 评论 复制链接分享
  • weixin_39957186 weixin_39957186 4月前

    A lot of it will not fit stuff seems to come from people only used to PC (winders/linux/Mac) space where things are huge and bloated. The micro world (6502/1802/8080/z80/6800) people were used to limited ram and efficient code was the rule so much of the stuff from then will fit easily. Forth was one such item of code.

    Allison

    点赞 评论 复制链接分享
  • weixin_39957186 weixin_39957186 4月前

    Looked in my Forth folder and: Camel Forth Z80 for CP/M, NS*dos and a standalone version with a bag and tag file system for a simple 765 based FDC. All three came form the Teserect BBS around '84ish. The largest is the standalone and its under 8K. They were PD then.

    There was an 8080, PDP-11(RT-11 ) and 6502 (apple prodos) version as well.

    点赞 评论 复制链接分享
  • weixin_39637646 weixin_39637646 4月前

    Openboot Openbios and OpenBsd are examples of using Forth as OS. Camelforth will start a Forth from hex code, as also any FIG forth for Z80, there are many free listings. Have a look at my collection of videos on Youtube so you can learn more about forth. This is my contact form you can reach me by email and I will answer your questions and try to help. https://sites.google.com/view/win32forth/home/contact (Forth was 16 bit till 90´s then when the 32 bit CPUs arrived, Forth became the facto 32 bit as standart. There are also 64bits Forth, and no reason to make 128 bits forths or higher, since forth is very flexible and real easy to implement on any hardware) Another good example of the Z80 Forth systems is the Jupiter Ace https://en.wikipedia.org/wiki/Jupiter_Ace

    点赞 评论 复制链接分享
  • weixin_39548805 weixin_39548805 4月前

    I just want to bring up the fact that lbForth Lite exists. It's a Forth cross-compiler for tiny devices. The cross-compiler targets many of the CPU's appears to be interested in getting CollapseOS up and running on. It looks like adding additional CPU targets such as the Z80 wouldn't be all that difficult for someone who has a decent grasp of that architecture.

    From what I can see the current list of CPU's is:

    • MOS 6502
    • C8051
    • AVR
    • MSP430
    • PDP8
    • PIC
    • STM8
    • THUMB

    While this won't directly help you with a native Forth compiler, getting cross-compiler going is likely to be a huge help every time you add a new architecture. To help you wrap your head around Forth there is an excellent 10 article series that walks the reader through writing a Forth compiler. This is basically the "guts" of CamelForth (GPL3) which someone else already mentioned. Here is the link to the CamelForth source code.

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    I'd like to let people know that I started, as an experiment, a reboot of Collapse OS as a Forth: https://github.com/hsoft/collapseforth . The goal is too bootstrap this Collapse OS-to-be entirely through that evolving Forth.

    I'm learning Forth as I go. I'd be curious to hear about what people experienced in Forth think of this approach.

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    The approach I took with that "collapseforth" reboot was a dead end, but it made me learn a bit more about Forth and I like it. I've added apps/forth, a new z80 implementation of Forth, in Collapse OS directly. With time, I can very well see it take a central place and make Collapse OS self-hosting in an even compacter way.

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    I'm changing the title of this issue because I can see the distinct possibility of making Forth take over Collapse OS. My expectation is that, because higher order words are more powerful, they are also more compact.

    With any other higher order language, this high level comes at a prohibitive cost in terms of implementation complexity (and thus RAM usage), but not with Forth, which is what makes it so interesting.

    Collapse OS currently self-hosts with about 10K of ROM and 8K of RAM. The vast majority of that space is zasm's complexity. I believe that with Forth very quickly (in terms of complexity) bootstrapping into higher order words, it makes its "self complexity" (the complexity it needs to self-host entirely) much lower, I can achieve similar or lower requirements and get a high-level language (and arch-independent!) as a bonus. This makes Forth very exciting.

    I'm not certain of success yet, but I'm optimistic and excited. Expect Forth to "eat away" (I will not do a reboot, just an incremental "code cancer") current ASM code.in the following days.

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    By the way, sorry to Forth enthusiasts for not having seen its potential early. It's difficult to see it without diving into it. It's such a wicked way to approach computing in general. I'll have to supply Collapse OS doc with good Forth introductory material.

    点赞 评论 复制链接分享
  • weixin_39960147 weixin_39960147 4月前

    seek "thinking forth", http://thinking-forth.sourceforge.net/

    all 2 cents.

    On Thu, Mar 12, 2020 at 9:14 AM Virgil Dupras wrote:

    By the way, sorry to Forth enthusiasts for not having seen its potential early. It's difficult to see it without diving into it. It's such a wicked way to approach computing in general. I'll have to supply Collapse OS doc with good Forth introductory material.

    — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hsoft/collapseos/issues/4#issuecomment-598153682, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADR73T3YGT34PTOIGWABAKLRHDG33ANCNFSM4I6UHPSA .

    --

    "Sling and move continents, a rock at a time."

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    yes, it's been on my reading list. I've started reading it, but my hands are too dirty playing with code. If I were reasonable, I'd take the time to step back and read this...

    点赞 评论 复制链接分享
  • weixin_39960147 weixin_39960147 4月前

    If you can minimize assembler startup, just for interpreter and few words, you can have a real "colapse" OS

    On Thu, Mar 12, 2020 at 9:14 AM Alvaro Barcellos wrote:

    seek "thinking forth", http://thinking-forth.sourceforge.net/

    all 2 cents.

    On Thu, Mar 12, 2020 at 9:14 AM Virgil Dupras wrote:

    By the way, sorry to Forth enthusiasts for not having seen its potential early. It's difficult to see it without diving into it. It's such a wicked way to approach computing in general. I'll have to supply Collapse OS doc with good Forth introductory material.

    — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hsoft/collapseos/issues/4#issuecomment-598153682, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADR73T3YGT34PTOIGWABAKLRHDG33ANCNFSM4I6UHPSA .

    --

    "Sling and move continents, a rock at a time."

    --

    "Sling and move continents, a rock at a time."

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    yes, that's also my understanding and my general approach. The path to use to get there is still a bit fuzzy, but I can see the destination.

    点赞 评论 复制链接分享
  • weixin_39758494 weixin_39758494 4月前

    Hello. Just a feedback from a Forth enthusiast: the path this project is taking is super interesting!

    点赞 评论 复制链接分享
  • weixin_39637386 weixin_39637386 4月前

    I will be reading this books, thanks.

    For me forth is just an annoying RPN language that cant do much besides 1 2 + . , but this whole enthusiasm may be an occasion to reconsider my feelings.

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    FORTH came a lot in the different comments I got. I knew it by name, but I've been convinced to look more into it, which I started to. We'll probably want a FORTH interpreter, yes.

    点赞 评论 复制链接分享
  • weixin_39712611 weixin_39712611 4月前

    Forth is often denser than assembly code. It's very portable and only takes a tiny kernel. It seems absolutely ideal for this project. For example: the book Threaded Interpretive Languages covers most of the implementation details.

    The big problem with Forth is that it can often be difficult to understand. Easer to understand but not quite so compact and somewhat slower is LISP. It would be another good language for this kind of project -- again it only requires a tiny kernel.

    点赞 评论 复制链接分享
  • weixin_39993301 weixin_39993301 4月前

    Lisp has more compiler overhead, kind of. The dictionary would be bigger (because they use full names like read-file instead of something like F<) but compiled code would ultimately be pointers in both. And having to read an entire function definition before compiling it (I suspect Forth can just 1:1 words with machine code, which does work even if the result is sub-optimal.)

    Not much of a reason it should run slower afterwards though. You could probably compile the Lisp to Forth in the background.

    点赞 评论 复制链接分享
  • weixin_39589394 weixin_39589394 4月前

    Including a variation on Jones FORTH targeted to the Z80 would be a nice addition.

    See https://github.com/nornagon/jonesforth/blob/master/jonesforth.S for most of the machine-specific code and what I think is the best example of literate programming I've ever seen! You start reading the comments at the top, with more and more bits of code interspersed and then by the time you reach the end of the file, you have the core of the FORTH kernel.

    The mode of presentation makes a great tool for someone that then would want to target some other hardware architecture.

    点赞 评论 复制链接分享
  • weixin_39589394 weixin_39589394 4月前

    Any chance of including a version of CamelForth with CollapseOS? I'd like to hear your thoughts.

    The other nice resource that accompany's CamelForth is a series of wonderful articles written about its design and implementation choices. Starting at https://www.bradrodriguez.com/papers/moving1.htm and following parts. Again, another great thing to have at your disposal when considering porting the FORTH kernel to a different CPU architecture.

    点赞 评论 复制链接分享
  • weixin_39811150 weixin_39811150 4月前

    We'll probably want a FORTH interpreter, yes.

    How does this help preserve humanity's ability to program microcontrollers with low-tech tools?

    I'm not saying there shouldn't be a FORTH interpreter! Just perhaps that the goal of the project isn't as clear to many of us as it could be.

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    from what I understand (still exploring this field), bootstrapped FORTH could be as compact if not more compact than straight ASM. This makes it an interesting path to explore.

    点赞 评论 复制链接分享
  • weixin_39960147 weixin_39960147 4月前

    2 cents. I understood the Z80 as a basic model for development and testing, to be easy translated into many cpu;

    A minimal system, must have a VT100 emulator, and parameters for boot and devices.

    As tools, a forth interpreter is a bonus to make a C compiler and then all tools.

    On Wed, Oct 16, 2019 at 2:02 PM Virgil Dupras wrote:

    https://github.com/jes from what I understand (still exploring this field), bootstrapped FORTH could be as compact if not more compact than straight ASM. This makes it an interesting path to explore.

    — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hsoft/collapseos/issues/4?email_source=notifications&email_token=ADR73T4GFCEHPV26CH5PVATQO5CLDA5CNFSM4I6UHPSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBNG7LI#issuecomment-542797741, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADR73T57FUSMRATXBPKBLXTQO5CLDANCNFSM4I6UHPSA .

    --

    "Sling and move continents, a rock at a time."

    点赞 评论 复制链接分享
  • weixin_39772388 weixin_39772388 4月前

    Every programmer (or very nearly) learns some assembly. It's ugly and painful but easy enough to grok once you realize how dumb a computer is (that's the point of learning assembly, I think). A quick poll around (large company of programmers) reveals nobody knows any forth. Perhaps it is mainstream in some community, and perhaps it is the best tool for this job, but if accessibility is the goal, then this goes against the utility to any non-specialized technologist / programmer post-collapse.

    This is not an argument against FORTH, which might be the shiniest bit of bits around, but an argument against the accessibility penalty of collapseos. Granted, I'm a non-contributing spectator at the moment, so take this with a grain of salt.

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    Thanks for the Moving Forth link. It's very interesting.

    I've been exploring Forth and it's a fascinating field, but too time consuming to explore and I'll think I'll stop there. So far, what I've read on that subject made me come to a few conclusions. Please, someone more knowledgable correct me if I'm wrong.

    Forth only deals with 16-bit numbers

    Even on 8-bit CPUs, it doesn't seem imaginable to have a forth with 8-bit cells. Making all operations of a 8-bit CPU 16-bit seems a bit wasteful to me. Doesn't Forth incur a heavy performance penalty compared to hand-written assembly?

    Forth has many layers of indirection

    I looked at how threads work in Forth and although we can't call this an interpreted language, it seems to me that there's much more indirection than in assembly language we see in current Collapse OS code. That would, again, incur a heavy performance penalty.

    Is Camel Forth self-hosting?

    Unless I'm missing something, CamelFoth is written in z80 assembly, but it doesn't include a z80 assembler. To make CamelFoth self-hosting, a z80 assembler would need to be written in Forth.

    Conclusion

    Unless I'm missing something (I probably am, but please correct me), these points above would definitely rule out Forth as being the "foundation language" for Collapse OS: too wasteful with regards to resources.

    If someone wanted to port CamelForth to Collapse OS' (which would probably be a minor task considering that it can be trivially made self standalone), I'd say it would be a nice addition, but as says, I'm not sure how it brings Collapse OS' closer to its goal.

    Side note: when trying to answer "does someone know of a z80 assembler in Forth?" question, I came across https://github.com/siraben/zkeme80 which looks nice. But it seems that its assembler is written in Scheme, so the question still stands.

    点赞 评论 复制链接分享
  • weixin_39942572 weixin_39942572 4月前

    Some further research I've made led me to https://www.bradrodriguez.com/papers/tcjassem.txt (Brad again!) which would seem to indicate that Forth is well suited for writing assemblers.

    点赞 评论 复制链接分享
  • weixin_39957186 weixin_39957186 4月前

    I've seen stand alone forth that fits in something like 8k rom. The 1802 based ELF2000 system has Forth in eprom, along with a monitor, bios, library routines, and even tiny basic and an editor. Forth is a very compact language.

    I'm not a forth fan it makes my head hurt but have used it and it does seem efficient. Much more so than NASCOM basic.

    Allison

    点赞 评论 复制链接分享
  • weixin_39960147 weixin_39960147 4月前

    And a formal C compiler, with cpp c1 c2, could be made in forth.

    On Tue, Nov 12, 2019 at 1:40 AM Allisontheolder wrote:

    I've seen stand alone forth that fits in something like 8k rom. The 1802 based ELF2000 system has Forth in eprom, along with a monitor, bios, library routines, and even tiny basic and an editor. Forth is a very compact language.

    I'm not a forth fan it makes my head hurt but have used it and it does seem efficient. Much more so than NASCOM basic.

    Allison

    — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hsoft/collapseos/issues/4?email_source=notifications&email_token=ADR73T6INBR5L6CZCYLL7QLQTIXSDA5CNFSM4I6UHPSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDZAEPA#issuecomment-552731196, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADR73TYZSL7YORLM5T2X24DQTIXSDANCNFSM4I6UHPSA .

    --

    "Sling and move continents, a rock at a time."

    点赞 评论 复制链接分享
  • weixin_39525865 weixin_39525865 4月前

    and mruby ;) 400KiB are needed

    点赞 评论 复制链接分享
  • weixin_39525865 weixin_39525865 4月前

    and mruby ;) 400KiB are needed

    点赞 评论 复制链接分享
  • weixin_39993301 weixin_39993301 4月前

    I would suggest changing the question to one about including a FORTH at all.

    FORTH having a low burden to get an environment running on exotic hardware is one of its most significant benefits.

    Though mostly in that FORTH code is just barely a veneer over stack machine assembly. It might also be worth looking at old Z80 interpreters (should be able to find them around old infocom fandoms, since they like to keep that stuff alive) or various small VMs (RetroFORTH's Nga and Ngaro are well documented and tiny, Lua's VM design is very battle tested, and I think Janet's is basically Lua but on a stack machine)

    You just need a VM which is easy to port, and then you can run whatever compilers on top of that :wink: Amusingly, the need to be portable across multiple different computing platforms (even though they were still mostly Z80's) is one of the reasons scripting used to be so prevalent in the Amstraad days.

    点赞 评论 复制链接分享
  • weixin_39960147 weixin_39960147 4月前

    I agree, a minimal stack forth can support a environment OS and be used to make compilers and "primal" archive functions.

    点赞 评论 复制链接分享

相关推荐