5 ms·

Author here. Absolutely. I used to love Turbo Pascal and Delphi when I was younger. If Free Pascal uses GNU LD.BFD or LLVM LLD when it links programs, then all

by jart 6y ago

Author here. Absolutely. I used to love Turbo Pascal and Delphi when I was younger. If Free Pascal uses GNU LD.BFD or LLVM LLD when it links programs, then all you'd need to do is is configure it to use cosmopolitan.a when linking system call functions like read(), write(), etc. See https://github.com/jart/cosmopolitan https://github.com/jart/cosmopolitan Another option is if Free Pascal wants to write all the system call support from scratch, then doing that now is going to be a whole lot easier since the Cosmopolitan codebase does a really good job documenting all the magic numbers you'll need. See files like https://github.com/jart/cosmopolitan/blob/master/libc/sysv/syscalls.sh https://github.com/jart/cosmopolitan/blob/master/libc/sysv/s... and https://github.com/jart/cosmopolitan/blob/master/libc/sysv/consts.sh https://github.com/jart/cosmopolitan/blob/master/libc/sysv/c... I've been working on a tiny C11 compiler called chibicc which has most GNU extensions and I managed to get it working as an actually portable executable with an integrated assembler: https://github.com/jart/cosmopolitan/blob/master/third_party/chibicc/README.cosmo https://github.com/jart/cosmopolitan/blob/master/third_party... I also got Antirez's KILO text editor working as an APE binary. https://github.com/jart/cosmopolitan/blob/master/examples/kilo.c https://github.com/jart/cosmopolitan/blob/master/examples/ki... If we can build a linker too then we can get a freestanding single file toolchain + ide that's able to be a modern version of Turbo C.

akavel 6y ago
I think the Zig community/BDFL might appreciate adding an APE target "os" to their buildchain (LLVM-based); that could be a match made in heaven!
- jart 6y ago
  Author here. I've been chatting with the Zig BDFL on Twitter recently about contributing APE support and he's been super supportive so far. It's going to be a nontrivial undertaking but would certainly be rewarding for everyone if we can make it happen.
  - akavel 6y ago
    Oh wow!!!!!!!
  - phabora 6y ago
    You can also use proper nouns, you dorks.
  - InitEnabler 6y ago
    Very cool! Maybe I should give Zig a try too. Also hats off to you @jart! Is this a one time thing or are you thinking of something bigger going with this project?
  - dom96 6y ago
    If you're interested, I'd expect adding support for this to the Nim programming language would be more trivial since Nim compiles to C. I had a quick look into doing this on your original thread[1], but got stuck pretty early on and just didn't have the time to get back into it. If that's something you'd be willing to pursue I'd love to help any way I can. Feel free to DM me on Twitter[2] any time. 1 - https://news.ycombinator.com/item?id=25558643 https://news.ycombinator.com/item?id=25558643 2 - https://twitter.com/d0m96 https://twitter.com/d0m96
ronyeh 6y ago
Since I can't upvote your Show HN twice, I'll upvote this comment. I learned something interesting tonight from your websites. Thanks! chibicc is a really fun idea! If I was in college, I would take a compiler course from you. Taken from your README: "chibicc is developed as the reference implementation for a book I'm currently writing about the C compiler and the low-level programming. The book covers the vast topic with an incremental approach; in the first chapter, readers will implement a "compiler" that accepts just a single number as a "language", which will then gain one feature at a time in each section of the book until the language that the compiler accepts matches what the C11 spec specifies. I took this incremental approach from the paper by Abdulaziz Ghuloum."
- xearl 6y ago
  chibicc is actually written by Rui Ueyama. Github: https://github.com/rui314/chibicc https://github.com/rui314/chibicc Previous HN: https://news.ycombinator.com/item?id=24676851 https://news.ycombinator.com/item?id=24676851
  - ronyeh 6y ago
    I see. My mistake. So jart is trying to turn it into a APE? I learn something new with every comment. So I would edit my comment to say: I'd love to take a compiler course from Rui, and a systems course from jart.
- ronyeh 6y ago
  Edit: as pointed out by xearl, I accidentally copied the README from github user https://github.com/rui314 https://github.com/rui314 and attributed it incorrectly to jart. That's what I get for browsing HN on my phone late at night.
mhd 6y ago
Speaking of other languages, given that the APE is a zip container, it shouldn't be too hard to have a "starkit" like setup where the binary part is basically node/python/perl/tcl and the main script and all required libraries are in the executable.
whizzter 6y ago
I love what you've produced here. I noticed that pthreads seems to be fail-stubbed for the time being, i guess it's a todo with tricky semantics? As for holding off on UI for the time being is probably the right thing to do, keeping with the minimal style planning on going for raw-x11,etc. However, as much as I personally love plain framebuffers (late 90s democoder myself), it'd be totally non-accessible for "plain" applications and totally lacking performance compared to anything accelerated when it comes to rendering. Graphics cards are just so many times faster that it's not really even the same kind of usage (only sad part is Apple punting on OpenGL driver updates even if Intel on the low end has become so much better). That said, having looked for a minimal UI framework and sadly they seem to be far inbetween these days (libUI is fairly compact on win/osX but required GTK on *nix but they've lost a bit of steam since 2018) Best of luck on it all (hopefully I can snatch out some time to contribute)
- jart 6y ago
  So far the only platform where I've managed to get threads to work has been Windows. I came pretty close to getting clone() on Linux working a few days ago. Threads are so hard because no API was ever defined for them in original UNIX and BSD, so therefore each modern system today does them in a completely different way. Another blocker is that not all operating systems let us modify segment registers which is something that the Linux compiler assumes is available for TLS. So it'd be a miracle if it ended up being possible to make threads work portably. fork() on the other hand was easy to get working on all platforms. I love fork() and vfork(). As for GUIs I'm still open to merging raw x11 support. One tricky issue is that we'd need to define a new API that veneers framebuffers, and so far Cosmopolitan has mostly refrained from defining novel interfaces, since the focus has been twiddling with low level magic numbers in order to make the textbook interfaces we already have work everywhere!
  - whizzter 6y ago
    Ah segregs is gonna be a pita indeed if it's all hard-wired to the compiler. Considered making some way to add "portable" modules yet(generic APE code with plat-specific impls) to avoid adding stuff to the core? I know the default calling-conv is slightly different but maybe by smth like defining virtual ports? (ie "send" structs since alignment rules should be mostly the same?)
anthk 6y ago
Now you can port Slashem to more platforms than Nethack 3.4.3 itself :D
dicroce 6y ago
Hey, question... Is an LD_PRELOAD version of cosmopolitan possible?

by jart 6y ago

akavel 6y ago

I think the Zig community/BDFL might appreciate adding an APE target "os" to their buildchain (LLVM-based); that could be a match made in heaven!

jart 6y ago
Author here. I've been chatting with the Zig BDFL on Twitter recently about contributing APE support and he's been super supportive so far. It's going to be a nontrivial undertaking but would certainly be rewarding for everyone if we can make it happen.
- akavel 6y ago
  Oh wow!!!!!!!
- phabora 6y ago
  You can also use proper nouns, you dorks.
- InitEnabler 6y ago
  Very cool! Maybe I should give Zig a try too. Also hats off to you @jart! Is this a one time thing or are you thinking of something bigger going with this project?
- dom96 6y ago
  If you're interested, I'd expect adding support for this to the Nim programming language would be more trivial since Nim compiles to C. I had a quick look into doing this on your original thread[1], but got stuck pretty early on and just didn't have the time to get back into it. If that's something you'd be willing to pursue I'd love to help any way I can. Feel free to DM me on Twitter[2] any time. 1 - https://news.ycombinator.com/item?id=25558643 https://news.ycombinator.com/item?id=25558643 2 - https://twitter.com/d0m96 https://twitter.com/d0m96

ronyeh 6y ago

Since I can't upvote your Show HN twice, I'll upvote this comment. I learned something interesting tonight from your websites. Thanks! chibicc is a really fun idea! If I was in college, I would take a compiler course from you. Taken from your README: "chibicc is developed as the reference implementation for a book I'm currently writing about the C compiler and the low-level programming. The book covers the vast topic with an incremental approach; in the first chapter, readers will implement a "compiler" that accepts just a single number as a "language", which will then gain one feature at a time in each section of the book until the language that the compiler accepts matches what the C11 spec specifies. I took this incremental approach from the paper by Abdulaziz Ghuloum."

xearl 6y ago
chibicc is actually written by Rui Ueyama. Github: https://github.com/rui314/chibicc https://github.com/rui314/chibicc Previous HN: https://news.ycombinator.com/item?id=24676851 https://news.ycombinator.com/item?id=24676851
- ronyeh 6y ago
  I see. My mistake. So jart is trying to turn it into a APE? I learn something new with every comment. So I would edit my comment to say: I'd love to take a compiler course from Rui, and a systems course from jart.
ronyeh 6y ago
Edit: as pointed out by xearl, I accidentally copied the README from github user https://github.com/rui314 https://github.com/rui314 and attributed it incorrectly to jart. That's what I get for browsing HN on my phone late at night.

mhd 6y ago

Speaking of other languages, given that the APE is a zip container, it shouldn't be too hard to have a "starkit" like setup where the binary part is basically node/python/perl/tcl and the main script and all required libraries are in the executable.

whizzter 6y ago

I love what you've produced here. I noticed that pthreads seems to be fail-stubbed for the time being, i guess it's a todo with tricky semantics? As for holding off on UI for the time being is probably the right thing to do, keeping with the minimal style planning on going for raw-x11,etc. However, as much as I personally love plain framebuffers (late 90s democoder myself), it'd be totally non-accessible for "plain" applications and totally lacking performance compared to anything accelerated when it comes to rendering. Graphics cards are just so many times faster that it's not really even the same kind of usage (only sad part is Apple punting on OpenGL driver updates even if Intel on the low end has become so much better). That said, having looked for a minimal UI framework and sadly they seem to be far inbetween these days (libUI is fairly compact on win/osX but required GTK on *nix but they've lost a bit of steam since 2018) Best of luck on it all (hopefully I can snatch out some time to contribute)

jart 6y ago
So far the only platform where I've managed to get threads to work has been Windows. I came pretty close to getting clone() on Linux working a few days ago. Threads are so hard because no API was ever defined for them in original UNIX and BSD, so therefore each modern system today does them in a completely different way. Another blocker is that not all operating systems let us modify segment registers which is something that the Linux compiler assumes is available for TLS. So it'd be a miracle if it ended up being possible to make threads work portably. fork() on the other hand was easy to get working on all platforms. I love fork() and vfork(). As for GUIs I'm still open to merging raw x11 support. One tricky issue is that we'd need to define a new API that veneers framebuffers, and so far Cosmopolitan has mostly refrained from defining novel interfaces, since the focus has been twiddling with low level magic numbers in order to make the textbook interfaces we already have work everywhere!
- whizzter 6y ago
  Ah segregs is gonna be a pita indeed if it's all hard-wired to the compiler. Considered making some way to add "portable" modules yet(generic APE code with plat-specific impls) to avoid adding stuff to the core? I know the default calling-conv is slightly different but maybe by smth like defining virtual ports? (ie "send" structs since alignment rules should be mostly the same?)

anthk 6y ago

Now you can port Slashem to more platforms than Nethack 3.4.3 itself :D

dicroce 6y ago

Hey, question... Is an LD_PRELOAD version of cosmopolitan possible?