Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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?



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.


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?


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


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.


Oh boy, this is amazing! Thanks for the reference


The linker probably compacts all of the code blocks and generally futher optimizes the final binary size.


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 (:




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: