Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

x86 Bare Metal Examples

github.com

Post reply on HN
Print view View original

31–40 of 59 posts

Re: x86 Bare Metal Examples

#31

Post by pm215 »

cirosantilli wrote: post #16
self_awareness wrote: post #15

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.

Yes, here we go again: 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 ;-)

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.

Re: x86 Bare Metal Examples

#32

Post by klohto »

auto wrote: post #30
cirosantilli wrote: post #7

Earlier quoted context omitted.

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

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.

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

Re: x86 Bare Metal Examples

#33

Post by self_awareness »

cirosantilli wrote: post #16
self_awareness wrote: post #15

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.

Yes, here we go again: 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 ;-)

Okay I've sent you a pull request with a bare metal hello world example ;)

Re: x86 Bare Metal Examples

#35

Post by auto »

klohto wrote: post #32
auto wrote: post #30

Earlier quoted context omitted.

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.

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

I wrote C++ in college before I started with iOS/Obj-C around 2010, and 75% of my work from then until Swift launched was Obj-C, the rest was Java. So, just from a readability and writing standpoint, verbosity (or lack there of) was a huge win, however that's a bit subjective and more of an aesthetic reason.

1. I really like the let/var system, combined with the let/guard conditional assignments. It might not work for everyone, but I write cleaner code because of it. I also love optional chaining, and I've really molded my thinking around it, as it often encapsulates large chunks of logic in a single line (essentially, do we go past here or not, based on the state of the data and whether things are set/valid). It's null checking that doesn't feel bolted on.

2. Swift has made some big changes from release to release, sometimes breaking existing code, but my largest codebase is ~70k lines, and it's taken me at most a few hours to get rolling again (FWIW, the auto updater did not work for me on 2.2->3 I believe it was). That said, the changes are worthwhile. JSON (De)/Serialization built in via the Codable protocol was a big upgrade for me, removing a vast amount of boilerplate, as well as my reliance on a 3rd party library (although big thanks to NerdRanch for FreddyJSON, it served me well).

3. Speaking of 3rd party libraries, CocoaPods has treated me well. Easy to use, not too difficult to create your own custom libraries and manage them from your own git repos.

4. I know I don't use them to their full potential, but the higher order functions:

https://medium.com/@abhimuralidharan/higher-order-functions-...

are a real game changer. Those operations, combined with my own drive over the last ~5 years or so to write more tightly coupled, functional, code has resulted in far more maintainable, easy-for-humans-to-parse systems.

Granted, it's not all daisies and roses. I hate how it handles strings, and they can't seem to settle on an internal representation/manipulation mechanism. The safety of the whole ecosystem makes working with raw byte representations/pointers a bit of a hassle when you need to do it, but it isn't terrible/impossible.

I'm by no means an expert, and just by the nature of my work and my responsibilities (especially in other domains) I don't feel that I've had the chance to truly dig into the language for all it's worth. For instance, when I watched this video:

https://www.skilled.io/u/swiftsummit/server-side-swift-from-...

My mind was blown, and I didn't realize just how much I was under-leveraging the type system, and I hope to have some time to do a few personal projects to really integrate some of the more core pieces of the language into my workflow soon.

This is already huge and ranty, so if you have any pointed questions I'd be happy to take a stab.

Re: x86 Bare Metal Examples

#36

Post by cirosantilli »

Riverheart wrote: post #29
cirosantilli wrote: post #7

Earlier quoted context omitted.

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

Lots of good looking material in here. Thanks for sharing your knowledge. Semi unrelated, what's up with the script tags on the profile page?

I did a bit of webdev in the past, so just casually looking for XSS on GitHub / websites that integrate with it.

I'm not a security person though, more interested in performance stuff.

Re: x86 Bare Metal Examples

#37

Post by cirosantilli »

dvfjsdhgfv wrote: post #28
cirosantilli wrote: post #7

Earlier quoted context omitted.

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

Where can I find the list of words that will trigger the FW? Does this work with Chinese characters only or do Western words can also do the job?

Have a look at: https://github.com/cirosantilli/china-dictatorship/tree/00a2... The pinyin for most blocked characters / the Western name of events will likely also work.

Re: x86 Bare Metal Examples

#38

Post by swayvil »

emourkai wrote: post #4

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?

I hear he's passionate.

Re: x86 Bare Metal Examples

#39

Post by 0xcde4c3db »

OskarS wrote: post #22
z3t4 wrote: post #6

Earlier quoted context omitted.

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.

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.

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.
Post reply on HN