
x86 Bare Metal Examples - Cieplak
https://github.com/cirosantilli/x86-bare-metal-examples
======
oldsklgdfth
Looking at the skills section on his webpage:
[http://www.cirosantilli.com/skills/](http://www.cirosantilli.com/skills/)

This seems like the most honest self-assessment I have seen of one's skills.

~~~
cirosantilli
That was copied from failed Google interview BTW :-)

To me the main problem is that I'm always afraid to put a 5, who can not check
manuals? ;-)

I'm also more and more of the opinion that (impact of projects) is more
important than (current skills).

~~~
oldsklgdfth
I find this interesting because grade inflation is real. There are so many
straight A students that it loses it's value as a measure. But if you can do
something without looking it up I would agree that is proficient.

A good team member is a larger force multiplier than a single rockstar.

~~~
ddingus
I have found inverting this kind of question helps.

Rate your interest in the following:

Item A Item B

People tend to express high interest where they want to grow, or have need.

------
emourkai
I'm kind of curious who's behind this Ciro Santili guy.

He(?) seems to be doing a ton of interesting github repos, a great deal of
informative stackoverflow answers and who knows what else.

Also, some anti-CCP stuff in the profile?

~~~
cirosantilli
If you have any specific questions, fire away :-)

Homepage + social media links from there should give a good idea of who I am:
[http://www.cirosantilli.com](http://www.cirosantilli.com)

~~~
auto
Dang, while I'll appreciate your one compiled and one interpreted language way
of life (pragmatic!), this makes me sad:

> Swift: I’m not an Apple person.

I'll admit, if I wasn't a professional iOS code slinger I probably never would
have approached it, but at this point it's by far my favorite language to
write (especially prototype) in.

~~~
klohto
I'm on verge trying it. Would you like to share your opinion on why do you
consider it good?

~~~
nivenhuh
I am a big fan of Protocol-oriented development. It allows you to do
component-style programming, where it's very simple (swifty) to extend
functionality onto struct/classes in a easy to understand, reusable way.

Additionally, language features like guard/optionals/etc... allow you to deal
with error states & control flow easily.

Two good videos I'd recommend on protocol-oriented development:

Protocol-oriented programming in swift (part 1):
[https://developer.apple.com/videos/play/wwdc2015/408/](https://developer.apple.com/videos/play/wwdc2015/408/)

Protocol and value-oriented programming in UIKit apps (part 2):
[https://developer.apple.com/videos/play/wwdc2016/419](https://developer.apple.com/videos/play/wwdc2016/419)

------
_chiliconcarne
I'll drop a question since I see Ciro Santilli is around. I want to start
learning low level programming. Yet, I feel awfully overwhelmed every single
time I try. Any recommendations you might have?

~~~
cirosantilli
If you can choose still, study something that is related to laboratory work
rather than programming, because anyone can buy a laptop and learn to program,
but almost no one can access a lab.

If you can only program, first choose an application that you are passionate
about, that is new, hard and important, and then learn whatever you need to
achieve that goal. Application first, method later.

After that, if you still want to learn low level programming... :-) use
emulators + minimal examples like in my tutorials, read / step debug the
source of major projects and document that somewhere, and then try to modify
those major projects with useful extensions.

------
mammalutte
Do you have any hello-world examples of how to load a 64bit ELF kernel with a
GRUB2 bootloader? I don't mean Linux kernel, I literally mean a simple program
that only prints "hello world". Something like this [1] but in long mode.

[1] [https://wiki.osdev.org/Bare_Bones](https://wiki.osdev.org/Bare_Bones)

------
self_awareness
Using BIOS calls doesn't seem to be really "bare metal". One could use bios
interrupt to read data from a disk, or also one could use memory mapping with
a target device to write a device driver that could request the file. I find
the second case a "bare metal" approach.

Fortunately most of the bios examples are using bios_* filenames. Rest of the
files are very nice.

~~~
cirosantilli
Yes, here we go again:
[https://news.ycombinator.com/item?id=18532102](https://news.ycombinator.com/item?id=18532102)
:-)

I wonder how much lower level you can go with QEMU / how much it can match
real hardware.

Pull requests / links welcome ;-)

~~~
pm215
QEMU runs the 'seabios' bios image in the guest, so you could certainly run a
'bare metal' custom image instead of the default BIOS blob if you wanted. At
the basic level of "prod the UART, prod the timers" we should be a reasonable
match to real hardware. Running on real hardware without the BIOS would be
trickier as you start to need to do things like set up memory controllers,
which you can get away without on QEMU.

------
cyrusmg
What is the use-case in real life ?

Is it to run special lab/factory equipment ? Anyone here who develops for bare
metal - can you share any details?

~~~
z3t4
A dream I've had for a long time is to make an application that you boot into,
which is the only application on the computer, for maximum optimization.
Upgrades would be easy, just reboot the computer and load the new software.
Wouln't write everything in assembly though.

~~~
OskarS
The problem comes when you need to use any kind of hardware, all the drivers
would have to be part of your app. The "unikernel" concept however does some
version of this: loads a kernel which only supports the minimal amount of
functionality and drivers needed and with only a single address space for a
single app.

~~~
0xcde4c3db
Historically this was more tractable because driver code was much simpler and
there was a lot of cloning/emulation of "legacy" hardware interfaces (a lot of
this is still present on PC, despite vendors' desire to get rid of it).
Typically either the hardware capabilities were fundamentally narrower in
scope than modern hardware or the hardware had its own controller (sometimes
with more raw power than the host CPU...) that implemented an abstract
interface. A bare-metal VGA driver for a single mode is no more than a few
dozen lines of code, whereas a modern GPU driver stack literally has an
optimizing compiler built into it.

------
cerebrum
[http://menuetos.net/](http://menuetos.net/)

------
baybal2
You can use efi text mode or framebuffer these days.

~~~
cirosantilli
I wanted to do a proper UEFI example, but got lazy, sketch at:
[https://github.com/cirosantilli/x86-bare-metal-
examples/tree...](https://github.com/cirosantilli/x86-bare-metal-
examples/tree/28598672c95fc519a296132200cbcce9012fa7d3#uefi-example)

Links to minimal runnable working examples / patches welcome.

------
tempodox
"\n\r" should be "\r\n" (0D, 0A -> CR, LF).

~~~
cirosantilli
Do you mean at: [https://github.com/cirosantilli/x86-bare-metal-
examples/blob...](https://github.com/cirosantilli/x86-bare-metal-
examples/blob/28598672c95fc519a296132200cbcce9012fa7d3/bios_carriage_return.S)
? Does it make any difference in BIOS, where \n seems to be "move cursor down"
and "\r" seems to be "go to start of line"?

