[HN Gopher] Show HN: OSle - A 510 bytes OS in x86 assembly
___________________________________________________________________
Show HN: OSle - A 510 bytes OS in x86 assembly
(sorry about double posting, I forgot to put Show HN in front in
the original https://news.ycombinator.com/item?id=43863689 thread)
Hey all, As a follow up to my relatively successful series in x86
Assembly of last year[1], I started making an OS that fits in a
boot sector. I am purposefully not doing chain loading or multi-
stage to see how much I can squeeze out of 510bytes. It comes with
a file system, a shell, and a simple process management. Enough to
write non-trivial guest applications, like a text editor and even
some games. It's a lot of fun! It comes with an SDK and you can
play around with it in the browser to see what it looks like. The
aim is, as always, to make Assembly less scary and this time around
also OS development. [1]:
https://news.ycombinator.com/item?id=41571971
Author : shikaan
Score : 130 points
Date : 2025-05-02 05:53 UTC (17 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| yjftsjthsd-h wrote:
| Well that's cool. Does the name stand for something?
| shikaan wrote:
| The -le suffix is used in south of Germany for the small
| version of something. So OSle stands for small OS.
|
| I'm not a native speaker, so maybe somebody else can paint a
| better picture. I used it just because part of my extended
| family comes from there (:
|
| EDIT: s/prefix/suffix/
| unwind wrote:
| *suffix.
|
| A prefix goes before something.
| shikaan wrote:
| Indeed. Thanks for the correction; I edited the original
| message
| evertedsphere wrote:
| as seen also in _Spatzle_ , _Musli_ , or, to pick something
| more relevant on HN, the words _Brotli_ (or _Zopfli_ )
|
| -li is a different version of the same ending
| lloeki wrote:
| I live in Alsace, which is in France but has a German-like
| dialect (Alemannic)
|
| https://en.m.wikipedia.org/wiki/Alsatian_dialect
|
| -ele is used _a lot_ to denote something small, cute,
| adorable; maybe think of it as kind of like chibi (chibi) or
| -chiyan (-chan) in Japanese.
|
| Mann (man) => Mannele
| https://cookingwithbrendagantt.net/mannele-st-nicholas-
| bread...
|
| Katz (cat) => katzele (kitty)
|
| The suffix can be liberally (ab)used with any - native or
| foreign - word or (sur)name to emphatic or comedic effect.
|
| Here I kinda guessed the -le use was such but around here I
| would have said "OSele" (oh-ess-uh-luh)
| sim7c00 wrote:
| cool stuff, like you still fit quite a bit in there too, 510
| bytes can be tricky.
|
| if you want an ahci controller to 'see' it, it will need
| partition table too, which will make it even less bytes (or maybe
| cleverly encoded)
| shikaan wrote:
| I went back and forth about the file system and disk stuff a
| fair bunch, to be honest. Most of it, as you say, was mostly
| due to wrestling the space constraints.
|
| If one day I'll give in and take the shell out or go multi-
| stage, I will definitely look at that.
|
| Maybe it's worth blogging about the journey; it's been a few
| weeks of merciless trade-offs to reach a usable API. It can
| make for a fun read (:
|
| Thanks for taking a look!
| userbinator wrote:
| What sectors contain is irrelevant to AHCI. As long as the BIOS
| contains the appropriate interface to a block device, it can be
| used.
| fuzzfactor wrote:
| On projects like this, where the IMG is small enough, I would
| think it was ideal to include osle.img with the zip.
| mycatisblack wrote:
| Very cool! I have to ask: what would the total size be if the
| package included the bios functions?
|
| Also: what could be done if the size limit were 8kbyte like the
| mask-rom bios days?
|
| Thanks for pointing me towards the bosh emulator.
| shikaan wrote:
| Hey, thanks for taking a look!
|
| On the former, I have no idea how to estimate BIOS functions
| size. Maybe I could just peek into an image and get a sense for
| it...
|
| On the latter, with a 16x increase in available space, I guess
| I would do a much more thorough work in putting guardrails in
| place.
|
| The API currently comes with a couple of traps (e.g., file
| names can be duplicated, processes are cooperative, all file
| operations perform disk I/O...) and it essentially requires
| guest applications to know about BIOS services in order to
| function.
|
| Another sticky point I wish I had the space to address better
| are calling conventions, which I had to get rid of almost
| immediately to save on instructions.
|
| > Thanks for pointing me towards the bosh emulator.
|
| You're welcome! Bochs is such a nice tool which I discovered
| only for this project as well. It was a no-brainer, since I got
| no way to debug 16-bit assembly from QEMU (unless you go off
| and fork it[1])
|
| [1]:
| https://gist.github.com/Theldus/4e1efc07ec13fb84fa10c2f3d054...
| userbinator wrote:
| _what would the total size be if the package included the bios
| functions?_
|
| Probably a few dozen to over a hundred KB, maybe even over a
| MB, depending on the era of machine and what it has installed;
| e.g. the GPU option ROM would be included if you use int 10h,
| int 13h might be hooked by a disk adapter, and if you use int
| 16h to read from a USB keyboard, that'll go through the BIOS'
| USB stack which normally includes some code in SMM too.
| revskill wrote:
| All professors should be doing this decades ago right ?
| stonogo wrote:
| Why? That is to say: it's a really cool project, and clearly a
| labor of love, but from an academic perspective it's a
| collection of x86-specific commands.
| revskill wrote:
| I must be honest. Professors are not doing their good job
| here.
| nathell wrote:
| Some related stuff:
|
| In 2004, Gavin Barraclough's mini-OS [0] won the IOCCC, packing a
| 32-bit multitasking operating system for x86 computers, with GUI
| and filesystem, support for loading and executing user
| applications in ELF binary format, with PS/2 mouse and keyboard
| drivers, VESA graphics, a command shell, and an application into
| 3.5 KB of highly obfuscated C code.
|
| In 2021, Justine Tunney wrote SectorLISP [1], a Lisp
| implementation that fits into a bootsector and is able to run
| McCarthy's metacircular evaluator.
|
| [0]: https://www.ioccc.org/2004/gavin/index.html [1]:
| https://github.com/jart/sectorlisp
| 90s_dev wrote:
| Two questions:
|
| 1. I just saw how str_print is implemented. It's so short even
| though it's asm. Is this why nul-terminated strings were so
| popular and became the default in C? Would pascal strings be much
| longer/uglier/harder in asm?
|
| 2. Why is str_print repeated in multiple files? How would you do
| code sharing in asm? I assume str_print is currently not "static"
| and you'd have to make it so via linking or something, and then
| be able to get its address using an asm macro or something?
| shikaan wrote:
| 1. If you look through the commit history, you'll see that the
| first implementation was actually with Pascal strings.
|
| Printing with Pascal strings is actually shorter (you skip the
| null test, basically), but constructing Pascal strings to pass
| as an argument when they are not constants yielded much more
| code to prepare for that call. Had I had more leeway, I would
| have used Pascal strings, it much less headache.
|
| 2. Files in `/bin` all include from the SDK. You can pretty
| much do the same for utility functions.
|
| The includes, at least in nasm, are very much like copy-pasted
| code (or includes in C for that matter), and then you can just
| jump/call to the label.
|
| I did not do it because I haven't been able to get nasm to
| optimize away the code that I don't use, and I didn't want to
| bloat the binaries or make a file for a 5LOC function.
|
| All in all not good reasons in general, but it made sense to me
| in this context.
| 90s_dev wrote:
| Thanks for answering my questions. Your project is really
| really interesting.
|
| Two more questions if you find some spare time:
|
| 3. Why does it use tty for interrupts instead of directly
| calling int 10?
|
| 4. How does this even print to the screen or use a tty in the
| first place? Is it just something inherent in bios api?
| shikaan wrote:
| Hey, thanks for your interest in this project!
|
| 3. The tty interrupt advances the cursor along with
| printing. So, once again, I do it to save on some
| instructions. In the first iterations I wanted to retain
| more control (by printing and moving as separate
| operations) so that I could reuse this across the board,
| but eventually I ran out of space.
|
| 4. I am relying heavily on BIOS interrupts, which are
| criminally underdocumented. The most reliable source is
| Ralph Brown's documentation[1] which is very far from what
| I was expecting to be authoritative documentation. Turns
| out this collection is really good and basically _the_
| source of truth for BIOS interrupts.
|
| To answer your question, yes, this is basically calling the
| BIOS API.
|
| [1]: https://wiki.osdev.org/Ralf_Brown's_Interrupt_List
| rerdavies wrote:
| THIS is the bible for BIOS APIs"
|
| https://bitsavers.trailing-
| edge.com/pdf/ibm/pc/ps2/PS2_and_P...
|
| Complete with reference assembler source code.
| kachapopopow wrote:
| The linker probably compacts all of the code blocks and
| generally futher optimizes the final binary size.
| shikaan wrote:
| I would have assumed the same, but I haven't managed. On the
| other hand, I did not tinker too much with all these toggles;
| it's such a little amount of shared code (which is also
| partially different in some cases) that didn't particularly
| make sense to me.
|
| If you know how to make it happen and/or want to contribute,
| hit me up (:
| djaychela wrote:
| I have a more general question - what is the minimum that is
| needed to qualify as an operating system? Is there something
| agreed on generally? Searching operating system minimum
| requirements leads to the wrong kind of info for me....
___________________________________________________________________
(page generated 2025-05-02 23:02 UTC)