Proposal: Add bare metal support to Go

Re:Proposal: Add bare metal support to Go by Someone on Wednesday May 07, 2025 @04:07PM (#43920086)

FTA:

  // printk emits a single 8-bit character to standard output
  //
  //go:linkname printk runtime.printk
  func printk(c byte)

So, printing “Hello, world!”, necessarily will have to make 13 calls to this function. I think I would have required a printk that prints an array of bytes. I expect that can be significantly faster on lots of hardware.

In contrast, there’s

  // getRandomData generates len(b) random bytes and writes them into b
  //
  //go:linkname getRandomData runtime.getRandomData
  func getRandomData(b []byte)

Here, they seem to acknowledge that it can be faster to make a single call.

[ Parent | on HN ]

Re:Proposal: Add bare metal support to Go by jeroenhd on Wednesday May 07, 2025 @04:24PM (#43920224)

The method for printing uses an Intel UART driver to print characters. AFAIK, the standard low level UART generally only does single character transfers unless you write a (relatively) complex driver.

Rendering per string is better per string, but I'm not so sure how bad the difference is when it comes to UART but I doubt the system has enough throughput for the first implementation to matter.

[ Parent | on HN ]

Re:Proposal: Add bare metal support to Go by 90s_dev on Wednesday May 07, 2025 @04:51PM (#43920440)

I wonder if this is related to that bare metal bios os post from a week or so ago. I asked the author why he used tty asm calls to print instead of calling int 10 directly and he said it was more efficient, but for different reasons.

https://news.ycombinator.com/item?id=43873822

[ Parent | on HN ]

Re:Proposal: Add bare metal support to Go by Someone on Thursday May 08, 2025 @01:44AM (#43923387)

> The method for printing uses an Intel UART driver to print characters

The spec (rightfully) says “(e.g. serial console)”, not “Intel UART driver”.

You cannot know what bare metal you’re running on. On some hardware it could be sending data out over Bluetooth, USB or WiFi because that’s the only connection to the outside world.

[ Parent | on HN ]

Re:Proposal: Add bare metal support to Go by ronsor on Wednesday May 07, 2025 @05:06PM (#43920566)

Arguably `printk(c byte)` should be `printck(c byte)`, and there should be a separate `printk(s []byte)` that handles an array of bytes.

If `printk` isn't implemented, then fall back to repeated calls of `printck`.

[ Parent | on HN ]

Re:Proposal: Add bare metal support to Go by lcarsip on Thursday May 08, 2025 @05:50AM (#43924657)

printk is the low level primitive for stdout printing and it's done this way as low level drivers generally only accept single characters.

There are upper level functions which simply takes a []byte and make fmt.Printf() work seamlessly and effectively when not printing on an UART that only takes a single character as output.

In TamaGo stdout is primarily used for debugging.

[ Parent | on HN ]

Re:Proposal: Add bare metal support to Go by timewizard on Wednesday May 07, 2025 @05:13PM (#43920616)

> Here, they seem to acknowledge that it can be faster to make a single call.

It calls the internal Fill function to fill 4 bytes of the slice at a time. That calls the rng assembly stub function which uses 'rdrand' to get 32bits of random data. Which gets called len(b)/4 times.

I don't think they did it for speed but rather to be more idiomatic.

Anyways, OSDev has had a "Go Bare Bones" page for quite a while:

https://wiki.osdev.org/Go_Bare_Bones

[ Parent | on HN ]