4 ms·

From readme: > What is this useful for? Hard disagree with "nothing"! This could be a stage 1 compiler for running an entire OS from source. Tcc already demon

From readme: > What is this useful for? Hard disagree with "nothing"! This could be a stage 1 compiler for running an entire OS from source. Tcc already demonstrated this running Linux, but it takes significantly more than 512 bytes. Also: https://malleable.systems/ https://malleable.systems/

dale_glass 3y ago
I wonder how long it's going to take for Gentoo to adopt this.
Waterluvian 3y ago
“If you want to boot your OS from scratch…”
6581 3y ago
With builder-hex0, 512 bytes are more than enough. https://github.com/ironmeld/builder-hex0 https://github.com/ironmeld/builder-hex0
ColonelPhantom 3y ago
You'd also need to load the source code from disk. At the point where you're doing that, the 512-byte limit isn't really relevant anymore, and adding "loading code from disk" within the 512 bytes isn't exactly realistic.
- benj111 3y ago
  Movsb can move the data in one instruction so I don't see why it's 'unrealistic' I don't really get your objection. 512bytes is rather arbitrary, yes. But I don't see why it becomes less relevant when it's ram.
- londons_explore 3y ago
  BIOS systems can load a page from disk in just a couple of bytes (since you are calling into the BIOS to do the actual work for you). Obviously, if you want to read from a file, you have all the overhead of understanding a filesystem.
  - WaitWaitWha 3y ago
    > you have all the overhead of understanding a filesystem. No need. Read & write cluster/sector or block/page directly; BIOS already does that.
    - DougN7 3y ago
      Don’t you need to read a directory structure to know where the file’s sectors are, how many there are, etc, and thus need to understand the file system?
      - masklinn 3y ago
        You’d put the file contents at a static offset, or a location pointed to by the MBR or something.
      - EvanAnderson 3y ago
        You could do something really quick-and-dirty. Write the code into sequential sectors, put a sentinel value in the last sector to indicate the code ends. It wouldn't be at all good for in-place editing but it would be easy to load and parse the code.
bell-cot 3y ago
>> What is this useful for? Other than "look at really cool thing I made", I'm thinking it might have some nice Chain-of-Trust use cases. A 512-byte binary isn't hard to verify by hand. Vs. nobody can hope to verify that a modern multi-MB `cc` binary doesn't contain a back-door-maker for someone less trustworthy than Ken Thompson.
- CamperBob2 3y ago
  Intel: "LOL get your own microcode."
  - Brian_K_White 3y ago
    risc-v: "workin'n on it"
    - rollcat 3y ago
      How does an instruction set solve supply chain trust? I suggest you reconsider [1] & [2], but apply the thought process in the context of a physical CPU. The problem is not source access or patents, the problem is you don't have an electron microscope to look at these nanometers-wide elements; even if you did, it's still an insanely difficult process. [1]: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref... [2]: https://research.swtch.com/nih https://research.swtch.com/nih
      - Brian_K_White 3y ago
        Very simply, by not requiring Intel or AMD to produce the hardware to implement the isa. It's true, but irrelevant, that you can't trust a risc-v cpu from Intel any more than an x86 cpu from Intel. But I think the bulk of x86 and amd64 patents have expired since the 90's already, so I think you could have other suppliers designing and fabricating x86_64 royalty-free and open-source today just as well, and risc-v is particularly interesting at least as much for the simpler start-over design as for the pure unencumbered ip.
tromp 3y ago
It would be far more useful if it supported function arguments. I wonder how much of the other features they'd have to give up to support those within 512 bytes.
deleted 3y ago
[deleted]
f1shy 3y ago
That is the concept behind GNU MES [1] [1] https://www.gnu.org/software/mes/ https://www.gnu.org/software/mes/

dale_glass 3y ago

I wonder how long it's going to take for Gentoo to adopt this.

Waterluvian 3y ago

“If you want to boot your OS from scratch…”

6581 3y ago

With builder-hex0, 512 bytes are more than enough. https://github.com/ironmeld/builder-hex0 https://github.com/ironmeld/builder-hex0

ColonelPhantom 3y ago

You'd also need to load the source code from disk. At the point where you're doing that, the 512-byte limit isn't really relevant anymore, and adding "loading code from disk" within the 512 bytes isn't exactly realistic.

benj111 3y ago
Movsb can move the data in one instruction so I don't see why it's 'unrealistic' I don't really get your objection. 512bytes is rather arbitrary, yes. But I don't see why it becomes less relevant when it's ram.
londons_explore 3y ago
BIOS systems can load a page from disk in just a couple of bytes (since you are calling into the BIOS to do the actual work for you). Obviously, if you want to read from a file, you have all the overhead of understanding a filesystem.
- WaitWaitWha 3y ago
  > you have all the overhead of understanding a filesystem. No need. Read & write cluster/sector or block/page directly; BIOS already does that.
  - DougN7 3y ago
    Don’t you need to read a directory structure to know where the file’s sectors are, how many there are, etc, and thus need to understand the file system?
    - masklinn 3y ago
      You’d put the file contents at a static offset, or a location pointed to by the MBR or something.
    - EvanAnderson 3y ago
      You could do something really quick-and-dirty. Write the code into sequential sectors, put a sentinel value in the last sector to indicate the code ends. It wouldn't be at all good for in-place editing but it would be easy to load and parse the code.

bell-cot 3y ago

>> What is this useful for? Other than "look at really cool thing I made", I'm thinking it might have some nice Chain-of-Trust use cases. A 512-byte binary isn't hard to verify by hand. Vs. nobody can hope to verify that a modern multi-MB `cc` binary doesn't contain a back-door-maker for someone less trustworthy than Ken Thompson.

CamperBob2 3y ago
Intel: "LOL get your own microcode."
- Brian_K_White 3y ago
  risc-v: "workin'n on it"
  - rollcat 3y ago
    How does an instruction set solve supply chain trust? I suggest you reconsider [1] & [2], but apply the thought process in the context of a physical CPU. The problem is not source access or patents, the problem is you don't have an electron microscope to look at these nanometers-wide elements; even if you did, it's still an insanely difficult process. [1]: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref... [2]: https://research.swtch.com/nih https://research.swtch.com/nih
    - Brian_K_White 3y ago
      Very simply, by not requiring Intel or AMD to produce the hardware to implement the isa. It's true, but irrelevant, that you can't trust a risc-v cpu from Intel any more than an x86 cpu from Intel. But I think the bulk of x86 and amd64 patents have expired since the 90's already, so I think you could have other suppliers designing and fabricating x86_64 royalty-free and open-source today just as well, and risc-v is particularly interesting at least as much for the simpler start-over design as for the pure unencumbered ip.

tromp 3y ago

It would be far more useful if it supported function arguments. I wonder how much of the other features they'd have to give up to support those within 512 bytes.

deleted 3y ago

[deleted]

f1shy 3y ago

That is the concept behind GNU MES [1] [1] https://www.gnu.org/software/mes/ https://www.gnu.org/software/mes/