6 ms·

Interesting project. So far the only desktop OS + compiler I know that can be reasonably understood in its entirety is http://www.projectoberon.com http://www.

by eterps 7y ago

Interesting project. So far the only desktop OS + compiler I know that can be reasonably understood in its entirety is http://www.projectoberon.com http://www.projectoberon.com

snvzz 7y ago
I'd add TempleOS and its HolyC to that list.
- grawprog 7y ago
  TempleOS may be understandable, but trying to actually make and do anything with it's a completely different story.
e12e 7y ago
Some interesting parallels to choices made in Pascal in the second level language, too. I'm not convinced that this approach is the best - the first level language is a bit like "literal programming" machine code (not assembler) - but I think a level of simple substitution would help a bit (think m4 as an assembler) - allowing at least mnemonics. The insitence on numbers seem somewhat arbitrary as they still need to be translated from strings (letter sequences) to actual integers[e] - I don't think a table/variable look up would be too onerous. On the whole this feels a bit more convoluted than building a Forth as level one - but no matter what I applaud the effort. [e] assuming program source code is text, not binary? If it's binary I suppose "filtering out" comments might be an approach as opposed to "translating" the source.
- akkartik 7y ago
  This is a very acute critique, so it seems like the perfect place to elaborate on why I chose numbers. We tend to think of Assembly programming as using mnemonics, but really the names of instructions in x86 are more than that: there are 14 different kinds of add instructions (https://c9x.me/x86/html/file_module_x86_id_5.html https://c9x.me/x86/html/file_module_x86_id_5.html) If a single name can map to this many distinct cases, it's not a mnemonic anymore, it's a little more than that. When a single word can do so many different things, and when the underlying instruction set has gaps, it becomes hard to create good error messages. Oh you added two immediate values together. You can't do that. But what can you do? Any impedance mismatch between external notation and target format quickly adds to the amount of code needed to generate good, clear error messages. Since my goal was to build SubX in itself, it seemed like a good trade-off to force people to live closer to the target language. That makes the error messages easier to write. There's really only one case to address at any point. (The alternative would be to give each opcode a distinct mnemonic. Does that seem useful? I didn't initially think it was, but I'm open to trying it.)
  - e12e 7y ago
    Maybe I skimmed, but I didn't note anything on this (anything this clear at any rate) in the text. It certainly is a justification for exposing the different op codes. I still think symbolic names for symbolic numbers make sense,though. And I'm not sure a table in one place looses out on clarity. I do think it's good to re-think assembly notation (que gas/masm/nasm/x86/6800 notation wars). I guess I feel at the level of level 1 - there is some symbolic manipulation and meta programming already (eg loops, labels for computed jumps) - and that "dumb" replacement might even turn out to me more clear. Comments go away (replace with nothing), jump-to-labels become jump-to-offset, opcode mnemonic become binary numbers, numbers become binary numbers etc. I confess I wonder at the choice of 32bit as I find amd64 to be both clearer, more sane (better? Calling convention) - and it should be more powerful (eg more registers) - faster and allow addressing more memory (if/when that becomes and issue - say mapping an entiere 6tb drive into contiguous memory?).
    - akkartik 7y ago
      You're absolutely right, this wasn't in OP. It seemed like a minor detail at the time. What should the mnemonics be called? SubX is already quite verbose. Would you be willing to put up with long names like `add_immediate`? 32- vs 64-bit is certainly a subjective choice. I outlined some reasons for my choice a year ago: https://lobste.rs/s/jkmwer/what_are_you_working_on_this_week#c_rsqllg https://lobste.rs/s/jkmwer/what_are_you_working_on_this_week.... But 64-bit is certainly a valid processor to target.
      - e12e 7y ago
        Thanks for taking the time to reply. Is there really a 32 bit mode without segments ? I missed that last time I looked at assambly - I thought it was the other way around - you didn't escape them until you went 64bit. As for needing needing 32bit in 64bit - I guess it would depend a bit on if you could settle for a "all 64bit all the time" subset or not (ie: no 32bit integers)? Now, for mnemonics - I certainly don't know. I suppose I see why they're generally implied in most assemblers... I think add_i is still a lot more readable than 0x83 or whatever. Is there a system to the numbers? Could one "mask" immediate etc (eg ADD|I MEDIATE, MUL|IMMEDIATE or some such? Where the pipe implies xor or something (forgive me, I haven't touched shifts etc in years)). I generally prefer descriptive names to terse names - but for an assembler I don't think it fits to go overboard - not unless you expect to end up with a Forth-like quick ascent to abstraction (like building a macro/substitution that abstract away the add_immediate back to just add). I guess I'm starting to see why primitive text macros a la m4 made its way into no just C (the C preprocessor), but also in various forms in various assemblers... Anyway, as your system needs to to some parsing and expansion (eg: strings to binary numbers, loops, label computation) - would not exposing that as a macro/meta facility make sense? Maybe it's more of a level 2 thing in your design?
- todd8 7y ago
  An interesting thought experiment that I've pondered is what I would do if I was given a system that I had to program without even an assembler. I've programmed on systems where the only access was through direct memory access to the machines memory, and other systems that had a boot loading initiated by a button that started a paper tape reader. I've also used minicomputers that had to have instructions manually keyed in on binary panel switches directly into memory to start a card reader where the cards contained machine instructions to bootstrap the rest of the boot loader off of the remaining cards. In every case though, somewhere I had an assembler to write the code I needed. What would I do if I didn't even have an assembler? I could write one, but I don't want to do it in machine code. Now days, the easy way would be to simply construct a cross-compiler or cross-assembler that was written in say python on a different machine. One alternative is to build a hand assembled, really simple macro system. m4[0] or Calvin Mooers' TRAC[1] are possible prototypes, but these flexible macro systems would be difficult to hand compiler into machine code so one might get by with a really basic, more limited macro system. Then each machine instruction could be encoded as a macro and then a primitive assembler could be written as macros. However, real assemblers do more work, they generally take two passes because they allow symbols to be used instead of literal addresses. So the next step would be to program a real assembler using the primitive assembly language. After that I suppose a compiler for a simple language like Pascal, basic Lisp, or Per Brinch Hansen's Edison[2] language could be written in assembly language. Per Brinch Hansen provides the basic directions for construction a very simple operating system from scratch, including the assembler and compiler in the book Programming a Personal Computer[3]. [0] https://www.gnu.org/software/m4/ https://www.gnu.org/software/m4/ [1] https://dl.acm.org/citation.cfm?id=365270 https://dl.acm.org/citation.cfm?id=365270 [2] http://brinch-hansen.net/papers/1981b.pdf http://brinch-hansen.net/papers/1981b.pdf [3] https://www.amazon.com/Programming-personal-computer-Brinch-Hansen/dp/0137302673 https://www.amazon.com/Programming-personal-computer-Brinch-...
  - e12e 7y ago
    I seem to recall an old text file on programming with just debug.exe - I thought it was an early phrack magazine article - but I can't seem to find it now. The idea was similar to 5a here: http://phrack.org/issues/62/7.html http://phrack.org/issues/62/7.html But the text I'm thinking of was more a how-to on bootstrapping development under win 3.11 if you had no outside resorces, and just a plain install with no other development tools.

by eterps 7y ago

Interesting project. So far the only desktop OS + compiler I know that can be reasonably understood in its entirety is http://www.projectoberon.com http://www.projectoberon.com

snvzz 7y ago

I'd add TempleOS and its HolyC to that list.

grawprog 7y ago
TempleOS may be understandable, but trying to actually make and do anything with it's a completely different story.

e12e 7y ago

Some interesting parallels to choices made in Pascal in the second level language, too. I'm not convinced that this approach is the best - the first level language is a bit like "literal programming" machine code (not assembler) - but I think a level of simple substitution would help a bit (think m4 as an assembler) - allowing at least mnemonics. The insitence on numbers seem somewhat arbitrary as they still need to be translated from strings (letter sequences) to actual integers[e] - I don't think a table/variable look up would be too onerous. On the whole this feels a bit more convoluted than building a Forth as level one - but no matter what I applaud the effort. [e] assuming program source code is text, not binary? If it's binary I suppose "filtering out" comments might be an approach as opposed to "translating" the source.

akkartik 7y ago
This is a very acute critique, so it seems like the perfect place to elaborate on why I chose numbers. We tend to think of Assembly programming as using mnemonics, but really the names of instructions in x86 are more than that: there are 14 different kinds of add instructions (https://c9x.me/x86/html/file_module_x86_id_5.html https://c9x.me/x86/html/file_module_x86_id_5.html) If a single name can map to this many distinct cases, it's not a mnemonic anymore, it's a little more than that. When a single word can do so many different things, and when the underlying instruction set has gaps, it becomes hard to create good error messages. Oh you added two immediate values together. You can't do that. But what can you do? Any impedance mismatch between external notation and target format quickly adds to the amount of code needed to generate good, clear error messages. Since my goal was to build SubX in itself, it seemed like a good trade-off to force people to live closer to the target language. That makes the error messages easier to write. There's really only one case to address at any point. (The alternative would be to give each opcode a distinct mnemonic. Does that seem useful? I didn't initially think it was, but I'm open to trying it.)
- e12e 7y ago
  Maybe I skimmed, but I didn't note anything on this (anything this clear at any rate) in the text. It certainly is a justification for exposing the different op codes. I still think symbolic names for symbolic numbers make sense,though. And I'm not sure a table in one place looses out on clarity. I do think it's good to re-think assembly notation (que gas/masm/nasm/x86/6800 notation wars). I guess I feel at the level of level 1 - there is some symbolic manipulation and meta programming already (eg loops, labels for computed jumps) - and that "dumb" replacement might even turn out to me more clear. Comments go away (replace with nothing), jump-to-labels become jump-to-offset, opcode mnemonic become binary numbers, numbers become binary numbers etc. I confess I wonder at the choice of 32bit as I find amd64 to be both clearer, more sane (better? Calling convention) - and it should be more powerful (eg more registers) - faster and allow addressing more memory (if/when that becomes and issue - say mapping an entiere 6tb drive into contiguous memory?).
  - akkartik 7y ago
    You're absolutely right, this wasn't in OP. It seemed like a minor detail at the time. What should the mnemonics be called? SubX is already quite verbose. Would you be willing to put up with long names like `add_immediate`? 32- vs 64-bit is certainly a subjective choice. I outlined some reasons for my choice a year ago: https://lobste.rs/s/jkmwer/what_are_you_working_on_this_week#c_rsqllg https://lobste.rs/s/jkmwer/what_are_you_working_on_this_week.... But 64-bit is certainly a valid processor to target.
    - e12e 7y ago
      Thanks for taking the time to reply. Is there really a 32 bit mode without segments ? I missed that last time I looked at assambly - I thought it was the other way around - you didn't escape them until you went 64bit. As for needing needing 32bit in 64bit - I guess it would depend a bit on if you could settle for a "all 64bit all the time" subset or not (ie: no 32bit integers)? Now, for mnemonics - I certainly don't know. I suppose I see why they're generally implied in most assemblers... I think add_i is still a lot more readable than 0x83 or whatever. Is there a system to the numbers? Could one "mask" immediate etc (eg ADD|I MEDIATE, MUL|IMMEDIATE or some such? Where the pipe implies xor or something (forgive me, I haven't touched shifts etc in years)). I generally prefer descriptive names to terse names - but for an assembler I don't think it fits to go overboard - not unless you expect to end up with a Forth-like quick ascent to abstraction (like building a macro/substitution that abstract away the add_immediate back to just add). I guess I'm starting to see why primitive text macros a la m4 made its way into no just C (the C preprocessor), but also in various forms in various assemblers... Anyway, as your system needs to to some parsing and expansion (eg: strings to binary numbers, loops, label computation) - would not exposing that as a macro/meta facility make sense? Maybe it's more of a level 2 thing in your design?
todd8 7y ago
An interesting thought experiment that I've pondered is what I would do if I was given a system that I had to program without even an assembler. I've programmed on systems where the only access was through direct memory access to the machines memory, and other systems that had a boot loading initiated by a button that started a paper tape reader. I've also used minicomputers that had to have instructions manually keyed in on binary panel switches directly into memory to start a card reader where the cards contained machine instructions to bootstrap the rest of the boot loader off of the remaining cards. In every case though, somewhere I had an assembler to write the code I needed. What would I do if I didn't even have an assembler? I could write one, but I don't want to do it in machine code. Now days, the easy way would be to simply construct a cross-compiler or cross-assembler that was written in say python on a different machine. One alternative is to build a hand assembled, really simple macro system. m4[0] or Calvin Mooers' TRAC[1] are possible prototypes, but these flexible macro systems would be difficult to hand compiler into machine code so one might get by with a really basic, more limited macro system. Then each machine instruction could be encoded as a macro and then a primitive assembler could be written as macros. However, real assemblers do more work, they generally take two passes because they allow symbols to be used instead of literal addresses. So the next step would be to program a real assembler using the primitive assembly language. After that I suppose a compiler for a simple language like Pascal, basic Lisp, or Per Brinch Hansen's Edison[2] language could be written in assembly language. Per Brinch Hansen provides the basic directions for construction a very simple operating system from scratch, including the assembler and compiler in the book Programming a Personal Computer[3]. [0] https://www.gnu.org/software/m4/ https://www.gnu.org/software/m4/ [1] https://dl.acm.org/citation.cfm?id=365270 https://dl.acm.org/citation.cfm?id=365270 [2] http://brinch-hansen.net/papers/1981b.pdf http://brinch-hansen.net/papers/1981b.pdf [3] https://www.amazon.com/Programming-personal-computer-Brinch-Hansen/dp/0137302673 https://www.amazon.com/Programming-personal-computer-Brinch-...
- e12e 7y ago
  I seem to recall an old text file on programming with just debug.exe - I thought it was an early phrack magazine article - but I can't seem to find it now. The idea was similar to 5a here: http://phrack.org/issues/62/7.html http://phrack.org/issues/62/7.html But the text I'm thinking of was more a how-to on bootstrapping development under win 3.11 if you had no outside resorces, and just a plain install with no other development tools.