Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Wednesday June 10 2020, @02:57AM   Printer-friendly
from the a-new-OS-is-forth-coming dept.

It appears the leadership of Collapse OS have decided to switch from Z-80 to Forth. In this article, they explain their reasoning.

Collapse OS' first incarnation was written in Z80 assembler. One of the first feedbacks I had after it went viral was "why not Forth?". I briefly looked at it and it didn't seem such a great choice at first, so I first dismissed it. Then, I had what alcoholics refer to as a "Moment of clarity".

[...] The Z80 asm version of Collapse OS self-hosts on a RC2014 with a 5K shell on ROM, a 5K assembler binary loaded in RAM from SD card (but that could be in ROM, that's why I count it as ROM in my project's feature highlights) and 8K of RAM. That is, it can assemble itself from source within those resources.

[...] If I wanted to re-implement that assembler feature-for-feature in Forth, it would probably require much more resources to build. Even though higher level words are more compact, the base of the pyramid to get there couldn't compete with the straight assembler version. This was under this reasoning that I first dismissed Forth.

So, again, what makes Forth more compact than assembler? Simplicity. The particularity of Forth is that it begins "walking by itself", that is, implementing its own words from its base set, very, very early. This means that only a tiny part of it needs to be assembled into native code. This tiny part of native code requires much less tooling, and thus an assembler with much less features. This assembler requires less RAM.

What is more compact than something that doesn't exist? Even Z80 assembler can't beat the void.

That's how although Forth is not more compact that native code (duh!), a Forth Collapse OS achieves self-hosting with as much resources than its Z80 counterpart.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: -1, Offtopic) by Anonymous Coward on Wednesday June 10 2020, @03:17AM (3 children)

    by Anonymous Coward on Wednesday June 10 2020, @03:17AM (#1005627)

    We prepare for collapse instead just making things better? Are we that fucked up?

    • (Score: 1, Interesting) by Anonymous Coward on Wednesday June 10 2020, @08:29AM (1 child)

      by Anonymous Coward on Wednesday June 10 2020, @08:29AM (#1005729)

      if you are a student of history you realise collapse is inevitable. the myth of infinite progress is a capitalist invention non-aligned with reality

      • (Score: 3, Interesting) by bzipitidoo on Wednesday June 10 2020, @10:54AM

        by bzipitidoo (4388) on Wednesday June 10 2020, @10:54AM (#1005745) Journal

        Collapse is also a myth of sorts. One gets stuck on the notion that a collapse is complete and absolute, as if a stock market collapse would set the indexes all the way down to 0. The collapse of the Roman Empire was by no means so total. The political leadership changed dramatically. Some engineering and science was lost, such as concrete, which was not rediscovered until the 19th century. Latin fell into disuse.

        But, the Latin alphabet remained. The ideal of a unified polity, in which there was no destructive internecine competition with all its waste, remained. The environment was not greatly affected, but to the extent that it was, the collapse was almost entirely good for it.

        And now? How can we take a step back, without risking a collapse unprecedented in history? Nuclear weapons, you know.

    • (Score: 0) by Anonymous Coward on Wednesday June 10 2020, @01:22PM

      by Anonymous Coward on Wednesday June 10 2020, @01:22PM (#1005782)

      I'm not sold on the idea there will be a collapse. But consider that if there will be, creating CollapseOS can be the work of one or just a few contributors while preventing the collapse might take organized effort by tens of millions of people - or maybe hundreds of millions.

      It's not fucked up to realize that you can't solve the world's biggest problems alone, or just with your friends.

  • (Score: 4, Insightful) by driverless on Wednesday June 10 2020, @03:26AM (3 children)

    by driverless (4770) on Wednesday June 10 2020, @03:26AM (#1005629)

    Uhh... it's a minimal operating environment for a Z80, sort of like CP/M from nearly half a century ago but not as sophisticated. Why is this news?

    And if the news is Forth, that's also half a century old and since Forth is interactive it's been a sort of shell/operating system from day one. In particular microFORTH has been running on most of the popular 8-bit CPUs for 40+ years.

    • (Score: 0) by Anonymous Coward on Wednesday June 10 2020, @03:34AM

      by Anonymous Coward on Wednesday June 10 2020, @03:34AM (#1005637)

      CP/M doesn't self assembles on those kind of resources. Is microforth self-hosting on its target machines?

    • (Score: 5, Informative) by RamiK on Wednesday June 10 2020, @12:49PM

      by RamiK (1813) on Wednesday June 10 2020, @12:49PM (#1005775)

      Why Collapse OS?

      https://collapseos.org/why.html [collapseos.org]
      https://collapseos.org/roadmap.html [collapseos.org]

      It's a prepper's OS.

      Why is this news?

      Putting aside the civilization collapse silliness, we could use something like Open Firmware [wikipedia.org] with lots of input and storage peripheral drivers to kickstart new non-C-compatible architecture that's targeting MCUs. That is, future novel architectures would want to have a tiny MCU loading their actual OS into their novel compute cores instead of falling into the x86's dos mode pitfall or ending up like the RasPi with a custom written bootloader for each board version as it needs to support new peripheral since someone thought it would make sense having the proprietary GPU cores boot first.

      --
      compiling...
    • (Score: 0) by Anonymous Coward on Wednesday June 10 2020, @07:15PM

      by Anonymous Coward on Wednesday June 10 2020, @07:15PM (#1005947)

      Look at it this way: working on this keeps them off the streets and messing up traffic. We could use a lot more of that these days.

  • (Score: 2) by JoeMerchant on Wednesday June 10 2020, @03:31AM (6 children)

    by JoeMerchant (3937) on Wednesday June 10 2020, @03:31AM (#1005633)

    1995-ish, we did a project with a bunch of 6811's - one team member insisted on using his "familiar" 8088 can also do 6502 "free" compiler, the rest of us used Cosmic C which had an actual, functioning 6502 optimizer. The difference in the assembly code produced was dramatic, the optimized code was 2-3x as fast, and 5-10x smaller in many cases.

    If I were tasked with writing an 8 bit OS, I'm pretty sure I'd do it in C, maybe even C++ in some rare places - check the assembly that the compiler produced, but even in 1995 the good optimizers were as good as, often better than, hand coded assembly.

    --
    🌻🌻 [google.com]
    • (Score: 3, Insightful) by qzm on Wednesday June 10 2020, @04:36AM (5 children)

      by qzm (3260) on Wednesday June 10 2020, @04:36AM (#1005657)

      Did you actually READ the submission?

      His point is a self-hosting environment, which means you would need a C compiler... so be able to compile the environment on the environment (thats what self-hosting means).

      How exactly do you plan on fitting a C compiler in 5k?

      • (Score: 3, Touché) by maxwell demon on Wednesday June 10 2020, @06:52AM (2 children)

        by maxwell demon (1608) on Wednesday June 10 2020, @06:52AM (#1005703) Journal

        How exactly do you plan on fitting a C compiler in 5k?

        Maybe this way. [bellard.org]

        --
        The Tao of math: The numbers you can count are not the real numbers.
        • (Score: 1, Insightful) by Anonymous Coward on Wednesday June 10 2020, @10:45AM (1 child)

          by Anonymous Coward on Wednesday June 10 2020, @10:45AM (#1005743)

          Such a small subset of C, while very small (but also, depending on a multi-megabyte kernel), is much less useful one might think. You might find writing a self-hosting OS in this language very awkward.

          • (Score: 2) by maxwell demon on Thursday June 11 2020, @05:11AM

            by maxwell demon (1608) on Thursday June 11 2020, @05:11AM (#1006182) Journal

            but also, depending on a multi-megabyte kernel

            No. Those multi-megabyte kernels are the "compile everything in, just in case" distribution kernels. I strongly doubt a compiler would need anything that wasn't already in Linux 1.0 in its minimal configuration. Indeed, I suspect even the earliest released 0.x version had the ability to run a compiler.

            Unfortunately I couldn't find any data on the size of those early kernels. But then, even the earliest kernels had stuff that isn't strictly necessary for a compiler to run. For example, if you removed all the networking and multiuser code, I'm pretty sure you'd get a massive shrinkage of the kernel (it would no longer really be Linux, but the point is, it would still be able to run the compiler).

            --
            The Tao of math: The numbers you can count are not the real numbers.
      • (Score: 3, Insightful) by JoeMerchant on Wednesday June 10 2020, @11:49AM (1 child)

        by JoeMerchant (3937) on Wednesday June 10 2020, @11:49AM (#1005757)

        "Self hosting" is more than a little bit of a pointless exercise.

        Note: those 6811 compilers from 1995 were running on 1995 hardware, itself not too far removed from 8 bit capability, and with not too much effort a fully kitted 6811 (64K RAM, etc) could run a good C compiler with that 1995 level of compiler tech, but... what are you gaining?

        Sure, you can start with a Z80 chip and 5K of RAM and cobble up your Forth environment with nothing more than hand written assembly code on paper that you type in, or maybe dial in with a rotary dial system if you prefer that level of bootstrapping, but... at the end of the exercise... can you actually tell the difference between a primitive bootstrapped environment and one written on a modern PC, cross compiled with modern tools and downloaded into your 5K system? Assuming you're using a keyboard, monitor of some sort, and non-volatile storage media - where are the drivers for all that coming from? Do we also need to develop the graphics chip in a self-hosted Z80 environment? What's the RAM limit for the chip design software?

        --
        🌻🌻 [google.com]
        • (Score: 0) by Anonymous Coward on Wednesday June 10 2020, @11:54AM

          by Anonymous Coward on Wednesday June 10 2020, @11:54AM (#1005762)

          The idea is to have an OS that can still be deployed to another machine after the last modern computer dies.

  • (Score: 2, Insightful) by Anonymous Coward on Wednesday June 10 2020, @03:32AM (3 children)

    by Anonymous Coward on Wednesday June 10 2020, @03:32AM (#1005635)

    Forth seems popular with hobbyists who want to (re)invent a complete machine S/W architecture from the bottom up, with an interpreter running the whole show. Forth is a seductive choice because the language is SO SIMPLE. It's simple because there is not much distinction between the Forth "VM" (the guts of the interpreter) and the Forth language itself. Effectively, programming in Forth is programming in the "assembly language" of the Forth interpreter, a
      stack machine.

    If you don't write complicated software (example, you just write simple hardware access routines), this might be sufficient.
    For more complicated stuff, Forth doesn't scale at all. Forth also ties your code pretty hard to a fixed machine "word size" like 16 or 32 bits. Other intrepreted languages don't make you pick one wordsize nor do they even have a wordsize concept.

    • (Score: 4, Informative) by istartedi on Wednesday June 10 2020, @06:42AM

      by istartedi (123) on Wednesday June 10 2020, @06:42AM (#1005699) Journal

      Forth has been taken higher up than you might think. People have even written object systems in it, and added lambdas and other things that you might not expect. It's an odd thing to do, but I'm quite confident that Forth is flexible enough to overcome the word size "restrictions" of which you speak. After all, words are just data, and Forth can handle any data you can throw at it.

      For an example of something that's sort of what Forth would be if you made it higher level, google around for concatenative languages [wikipedia.org] such as Joy. It's an interesting little niche in the programming world.

      --
      Appended to the end of comments you post. Max: 120 chars.
    • (Score: 1, Insightful) by Anonymous Coward on Wednesday June 10 2020, @07:17PM

      by Anonymous Coward on Wednesday June 10 2020, @07:17PM (#1005948)

      Hobbies are supposed to be fun.

      For some people, coding in Forth is fun. I always enjoyed it.

      Sometimes things aren't complicated.

    • (Score: 3, Interesting) by hendrikboom on Thursday June 11 2020, @02:07PM

      by hendrikboom (1125) Subscriber Badge on Thursday June 11 2020, @02:07PM (#1006285) Homepage Journal

      On the now static TUNES forum, where they discussed building a modern verified OS from scratch, using modern verification tools as early in the bootstrapping as feasible, opinion was fairly divided about whether they should start with a Forth dialect or a Lisp/Scheme dialect.

      They never got together enough to build anything much, but their archived site [tunes.org] is a gold mine of information about related issues.

      -- hendrik

  • (Score: 1) by ealbers on Wednesday June 10 2020, @04:12AM (4 children)

    by ealbers (5715) on Wednesday June 10 2020, @04:12AM (#1005650)

    I mean seriously, wtf?
    I wrote a z80 forth interpreter in the 80's, on trs-80 model 1...why the f are we reading about this???
    These things are lovely, but really people, can we please move ON!

    • (Score: 2) by bzipitidoo on Wednesday June 10 2020, @10:19AM (3 children)

      by bzipitidoo (4388) on Wednesday June 10 2020, @10:19AM (#1005737) Journal

      The maintainer believes civilization is likely to collapse by 2030. Thinks this 40 year old tech will be the most advanced stuff we can handle after the collapse. Yeah, I also thought, "WTF?"

      • (Score: 2) by HiThere on Wednesday June 10 2020, @12:20PM (2 children)

        by HiThere (866) Subscriber Badge on Wednesday June 10 2020, @12:20PM (#1005770) Journal

        That's a weird combination of pessimism and optimism. After a real collapse the best we'll be able to manage is an abacus. Too much computer stuff, whatever level you're contemplating, is dependent on highly integrated specialists. After something slightly less major any desktop system should work as long as it keeps running.

        --
        Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
        • (Score: 1, Insightful) by Anonymous Coward on Wednesday June 10 2020, @12:31PM (1 child)

          by Anonymous Coward on Wednesday June 10 2020, @12:31PM (#1005772)

          > any desktop system should work as long as it keeps running

          Exactly. Collapse OS is for after that moment.

          • (Score: 2) by Bot on Thursday June 11 2020, @09:50PM

            by Bot (3902) on Thursday June 11 2020, @09:50PM (#1006609) Journal

            Basically some scavenged microcontrollers to design new processors to enable a factory to build proper CPUs to drive autonomous missiles to collapse civilization again 👍

            --
            Account abandoned.
  • (Score: -1, Troll) by Anonymous Coward on Wednesday June 10 2020, @04:49AM (4 children)

    by Anonymous Coward on Wednesday June 10 2020, @04:49AM (#1005661)

    "build and install Collapse OS without external resources (i.e. internet) on a machine of HER design"

    • (Score: -1, Troll) by Anonymous Coward on Wednesday June 10 2020, @11:15AM

      by Anonymous Coward on Wednesday June 10 2020, @11:15AM (#1005747)

      Poor victim!

    • (Score: 1, Insightful) by Anonymous Coward on Wednesday June 10 2020, @12:59PM (2 children)

      by Anonymous Coward on Wednesday June 10 2020, @12:59PM (#1005777)

      Is the author insisting you use that language? People are entitled to their opinions, where we draw the line is when they employ coercion to force those views onto others. That was the problem with '80s social conservative Christians as much as it's today a problem with SJW, BLM and Vanilla ISIS types. Disagree and get cancelled, just as you'd do to the author of this software. Be better!

      • (Score: 0) by Anonymous Coward on Wednesday June 10 2020, @04:04PM

        by Anonymous Coward on Wednesday June 10 2020, @04:04PM (#1005849)

        Actually, many places DO enforce a style guide where you've got to do ridiculous things to ensure gender inclusion for a non-gendered subject.
        The standard for a singular non-gendered pronoun is "he, him, his." I am sorry some people fail at English grammar.

      • (Score: 2) by Bot on Thursday June 11 2020, @09:24PM

        by Bot (3902) on Thursday June 11 2020, @09:24PM (#1006601) Journal

        >Is the author insisting you use that language?
        What a convoluted way to ask if it's a leftie.

        --
        Account abandoned.
  • (Score: 0) by Anonymous Coward on Wednesday June 10 2020, @05:11AM (5 children)

    by Anonymous Coward on Wednesday June 10 2020, @05:11AM (#1005667)

    The started music of CollapseOS is to preserve the ability to program microcontrollers in the case of civilizational collapse. However, it's the capability to produce hardware that is the issue, not software. How will they produce microcontrollers to program? There are enough rpis and arduinos around that I doubt you would need to cannibalize any of the ancient systems this thing runs on if you needed to control something.

    • (Score: 0) by Anonymous Coward on Wednesday June 10 2020, @05:15AM

      by Anonymous Coward on Wednesday June 10 2020, @05:15AM (#1005668)

      *The stated mission

    • (Score: 0) by Anonymous Coward on Wednesday June 10 2020, @01:45PM (3 children)

      by Anonymous Coward on Wednesday June 10 2020, @01:45PM (#1005789)

      If you read https://collapseos.org/why.html [collapseos.org] it states:

      Therefore, Collapse OS won't be actually useful before you and I are both long dead. However, communities with good foresight will immediately start to work on creating post-collapse computers because a lot of work will have to be poured on their own local copy of it before it runs smoothly on the hardware they manage to scavenge and retrofit. They also have to become proficient in maintaining it. Their children also have to.

      That's the perspective we have to keep in mind in this project. Collapse OS doesn't have to run smoothly, but it has to be easy to grok in its entirety and, most importantly, gather vital knowledge about as many components as possible in one self-contained place.

      So the author is assuming a collapse that takes the world's manufacturing to a 19th century level of technology. For the first 30 years or so, leftover computer parts from the modern era will still work. But eventually those will all wear out, even fanless and rugged designs, and humanity will have to start rebuilding their manufacturing tech. Reaching the sophistication required to make a new Z80 is far less effort than reaching the sophistication required to make a new Raspberry Pi Zero, so that's the target the author selected.

      I think it makes sense, if you believe there will be a collapse. I don't think there will be, not on the scale described.

      • (Score: 0) by Anonymous Coward on Wednesday June 10 2020, @04:30PM (1 child)

        by Anonymous Coward on Wednesday June 10 2020, @04:30PM (#1005859)

        It makes a certain kind of sense, but not much. Most of the consumer-grade equipment will be unusable due to age, EMP, or failed infrastructure, so you could see the knowledge disappear entirely in areas within a generation. Hydro and wind should be mostly unaffected, although installations could be targeted in whatever apocalyptic war caused the collapse. Solar would be unreliable in a nuclear winter situation, if it works at all. Hand-crank and crystal radios, but I've you'll need batteries at least for transmission. I imagine there will be relatively unaffected areas, with stable electrical generation capabilities, but manufacturing may have to be practically bootstrapped from nothing - any area with significant manufacturing capability will be a strategic target.

        • (Score: 1, Interesting) by Anonymous Coward on Wednesday June 10 2020, @09:36PM

          by Anonymous Coward on Wednesday June 10 2020, @09:36PM (#1006003)

          I think the more interesting task for someone preparing for a collapse would be writing a textbook on how to go from smelters and iron ore to Apollo-mission level computers.

          I also think the fact that so much can be done with 8k RAM is an indictment of 21st century society. Capitalism, to its credit, has pushed humanity to make mind-blowing advances in computing technology. But capitalism, to its condemnation, has pushed humanity to a disgracefully low focus on efficiency. I'm not blaming individual engineers, managers, teams, companies, or countries, the problem is just the whole system. Any team that's trying to make a nice application that runs quickly and securely with low resource utilization on twenty year old hardware will be crushed by competitors getting to market ten times as fast with something less than 1% as efficient.

      • (Score: 0) by Anonymous Coward on Tuesday June 16 2020, @06:47AM

        by Anonymous Coward on Tuesday June 16 2020, @06:47AM (#1008503)

        The four threat areas for old hardware are capacitors, corrosion, heat, and voltage irregularities. If you can scavenge the equipment to keep those all operating within specifications your hardware should last indefinitely (unless it had a manufacturing flaw that causes degradation after a while, like those Intel SATA controllers. Most of the 90s era Intel hardware, and even most clone hardware is solid however. Sparcs, MIPS, PA-RISCs, PPCs, and Alphas as well.

        Assuming most of it hasn't gotten recycled by now, finding any of this hardware to pilfer from older businesses after the collapse will be a major priority, as would certain museum's pieces. Given that a kid was able to produce his own... 6 junction IC/transitor, I think the time to regain transistor manufacturing will not be that long, so long as the requisite precursor metals can be mined and transported to wherever the fab will be. Precision machining will be the true crux, followed by high purity smelting. If equipment can be scavenged for those two aspects, and power supplied, the rest of civilization should be easy to bootstrap, given archives of old world knowledge. The loss of the knowledge on the other hand would be a hugely crippling blow.

        Having said all this: flash will be the most critical weak point in current hardware. If you're lucky you've got a maximum of 100 years before it's discharged completely. Modern hardware has signing keys that without the proper signed firmware will make it impossible to reinitialize even if you have code snippets that would work, and given Intel hardware with efused bioses (as well as game consoles), and AMD hardware with AGESA signing, none of the hardware past 2009/2012 will be usable without archived copies of the proper bios initialization. The others may be difficult or impossible, but as coreboot shows, it was possible to use information from one board to generalize and help port to a lot of other boards, meaning certain generations of hardware will be far more likely to survive and be useful for bootstrapping the 'recovered generation', if flash chips can be stockpiled in the proper formfactors/sizes (DIP28/32 parallel, DIP32/QFP FWH/LPC, DIP-8 SPI Flash, SOIC-8 SPI (Either with adapters for DIP8, or alternatively sockets for soldered down boards to be reworked.)

        There will be a lot of non-reusable junk thanks to our modern locked-in society, much of it without parts that can act as spares for what will function, unless you get luck with some of the passive components.

        For people who are serious prepping, make sure you buy 1000+ units (scaled based on your hardware's makeup of capacitors/resistors) in all the major through hole and surface mount sizes. The through hole caps are the most probable to fail over the course of their life, and they do have some chemical lifetime to them, which you might reach before technology is recovered.) But that is how you will get that few extra years out of the tech you have. For Intel/AMD, anything LGA775/AM3+ or below is the best hardware you can get that will boot without signing. GPUs may be a different matter and you may want PCI VGA cards, pre-3d for maximum chance of operation, although later cards MAY work, up to kepler on the nvidia side and anywhere from the HD2400 on up on the AMD side (some components in the vbios had signing prior to going all-in with the RX590/Vega+ hardware.)

  • (Score: 3, Touché) by Bot on Wednesday June 10 2020, @07:54AM

    by Bot (3902) on Wednesday June 10 2020, @07:54AM (#1005716) Journal

    -survivor
    -wat no eat me pls
    -no I need z80
    -for wat
    -to run collapseos
    -there is heap of pc next to that building
    -i know, all windows on x86, I need z80
    -have you found any b4
    -yep in a vibrator. Nap it is a Morse code buzzer
    -pretty useful
    -yep but not as b4

    --
    Account abandoned.
  • (Score: 2) by hendrikboom on Wednesday June 10 2020, @03:34PM (8 children)

    by hendrikboom (1125) Subscriber Badge on Wednesday June 10 2020, @03:34PM (#1005836) Homepage Journal

    Forth works quite well on a 16-bit machine. It's compact.

    But put it on a 64-bit machine ... suddenly every code syllable is 8 bytes wide instead of two.
    Compactness is gone. You'd want to go to a variable bit-length encoding. Simplicity and elegance are gone.

    • (Score: 0) by Anonymous Coward on Wednesday June 10 2020, @04:12PM (5 children)

      by Anonymous Coward on Wednesday June 10 2020, @04:12PM (#1005852)

      You are right.
      There is a reason Forth use peaked in the 1980s. Forth was a very good fit for the machine architectures and what was expected of them at the time: 16 bit CPU, no real OS as an abstraction like we have today, and single user machines running a single app at a time. Also, a simple commandline interface for everything. Think Commodore 64 but with a 16 bit processor. Also, an embedded device controlling one machine hooked up to it.

      • (Score: 1, Informative) by Anonymous Coward on Wednesday June 10 2020, @04:40PM (1 child)

        by Anonymous Coward on Wednesday June 10 2020, @04:40PM (#1005861)

        Chuck Moore is still designing forth chips - greenarraychips.com.

      • (Score: 3, Interesting) by hendrikboom on Wednesday June 10 2020, @10:53PM (2 children)

        by hendrikboom (1125) Subscriber Badge on Wednesday June 10 2020, @10:53PM (#1006046) Homepage Journal

        I once wrote a threaded-code concatenative-language interpreter in assembler with a garbage collector. The garbage collector was written in the same language it was collecting for. And it could collect code, including its own code.

        It was fun, but not greatly useful. The thing was a toy.

        I also had a C run-time system for use when debugging. That C system could do static type-checking.

        -- hendrik

        • (Score: 3, Funny) by Bot on Thursday June 11 2020, @09:53PM (1 child)

          by Bot (3902) on Thursday June 11 2020, @09:53PM (#1006611) Journal

          >The garbage collector was written in the same language it was collecting for. And it could collect code, including its own code

          sorry to be the one pointing that out, but, that inevitably means that the collected code was garbage.

          --
          Account abandoned.
          • (Score: 3, Informative) by hendrikboom on Friday June 12 2020, @02:04AM

            by hendrikboom (1125) Subscriber Badge on Friday June 12 2020, @02:04AM (#1006725) Homepage Journal

            True, but it did have to go through its own code (like all code) to determine its extent. It was a two-space copying garbage collector, and partway through the collection it would be executing its code both in the from and to spaces, depending where it happened to be at the time.

            -- hendrik

    • (Score: 2) by turgid on Friday June 12 2020, @07:06PM (1 child)

      by turgid (4318) Subscriber Badge on Friday June 12 2020, @07:06PM (#1007021) Journal

      But put it on a 64-bit machine ... suddenly every code syllable is 8 bytes wide instead of two.

      Only if you write it in bare assembly language on a RISC, surely?

      • (Score: 3, Insightful) by hendrikboom on Saturday June 13 2020, @10:55PM

        by hendrikboom (1125) Subscriber Badge on Saturday June 13 2020, @10:55PM (#1007587) Homepage Journal

        Only if you write it in bare assembly language on a RISC, surely?

        Well, the standard, elegant way to implement Forth is to have a Forth program be a series of addresses of functions to be called one after another. A Forth function would then start with a bit of machine code to start the address-fetcher and jumper-to loop on the addresses that follow it. Except the primitive operations, which would just be assembler.

        But on a 64-bit machine, addresses are now 8 bytes long. A huge waste of space for most code.

        You *could* byte-code and have a limit of 256 functions.
        Or restrict total memory to 64K out of your machine's available 8 gigabytes of RAM.
        Or other similar.

        Or, when storing Forth instructions into memory, you could translate them to in-place hardware machine code, and even do some optimization while you're at it. It might even come close to saving space.

        None of this really feels like the traditional simplicity of Forth. Though technically, I suppose it could still be called Forth.

        -- hendrik

(1)