Talk:Bare Bones

Renaming

Shouldn't this page get renamed? Because every other language's BareBone is called [Language Name] BareBone. Only the C/C++ BareBone site is called BareBone. I think it is reasonable, to rename it to C/C++ BareBone. Then we could use the BareBone page for other things, like explaining why there are BareBones and so on. Columbus 08:50, 14 September 2014 (CDT)

I would've also thought that 'x86 Bare Bones' might also be more appropriate, since that is what you're actually building here. --Ajxs 23:59, 23 April 2017 (CDT)

main -> kmain

I was the one who originally decided to use main() as function name. I changed my mind, because of the possibility of brain-dead compiler option choices resulting in a main()-related linker error, which might be less confusing if the function in the code is called kmain() instead. Solar 07:01, 27 February 2008 (CST)

64 bits

Hello from a new user.

I tried to assemble stuff from this article, but it was no go:

loader.s:21: Error: suffix or operands invalid for `push'
loader.s:22: Error: suffix or operands invalid for `push'

While browsing, I encountered indications it might be my architecture (64bit AMD). I know that cross-compiler would do the job (for 32 bit), but couldn't the code instead be written in such way, so that it is cross-architecture instead? That way, I'd have the solution for both architectures (no need for replacement code to this), and possibly wouldn't need to build a cross compiler at this point (very, very early).

Also, it would be very good if someone could explain, line by line, what's happening here.
In any case, looks like a small, but a very important rewrite is in order.

So, in short:

• Is it architecture specific?
• Any ideas about a workaround?
• Can someone explain the (new!) code?

--Paxcoder 21:57, 5 January 2009 (UTC)

First of all, questions belong on the forum, not in some talkpage few people ever bother to read.

What you have is an assembler that defaults to 64-bit code, and assembly that is written for 32-bit code. To GAS those two are completely different architectures (i386 vs x86-64). There is however a command-line switch that would tell GAS to assemble for the correct architecture and as such needs no change in this code. - Combuster 22:45, 5 January 2009 (UTC)

I hope you understand what you offered is not a solution. I want it to be able to run on 64 bit processors. Basically, you said very little. Nevermind. I'll use forum. --Paxcoder 20:42, 6 January 2009 (UTC)

Added question at the bottom of the page with the options I use to build on my 64-bit Ubuntu 10.04 laptop. -- Mbrush 03:04, 21 May 2010 (UTC)

Revert of -fno-leading-underscore

fixed minor mistake-meshounah

Depending on the compiler, leading underscores are either required or wrong. Also, the summary field was designed for these messages - Combuster 17:42, 11 August 2007 (CDT)

We should add either -fleading-underscore or -fno-leading-underscore to the gcc command. I'd personally prefer -fno-leading-underscore and removing all underscores from the NASM and GAS code. Any opinions on the matter? -Jhawthorn 19:04, 15 August 2007 (CDT)

I'd go for suggesting that a cross-compiler is the only guarantee for success - it also fixes several other things one's system compiler might try to annoy the user (things commandline arguments won't fix). Since the crosscompiler described does not add leading underscores, and the use of having them is purely legacy, I'd go for no underscores anyway. - Combuster 04:34, 17 August 2007 (CDT)

I reverted an edit from Hangin10 regarding -fno-leading-underscore. One of the advantages of the GCC Cross-Compiler is that it makes any tweaks regarding this option unnecessary. IMHO, if we start "leaking" such tweaks into this tutorial, we end up with a "Bare bones for Windows" and a "Bare bones for Linux" again. Or has there been a reason for this edit that I am unaware of? -- Solar 08:26, 19 January 2009 (UTC)

Agreed If you use a windows oriented compiler you get stuck with all its windows oriented dependencies. Better not to silently allow a timebomb to be constructed on a windows platform by disabling leading underscores, and just have everybody use the crosscompiler from day one. - Combuster 23:59, 19 January 2009 (UTC)

FPU Support

I reverted an edit from Hangin10 where the 'finit' instruction was added. IMO, FPU initialization doesn't belong in Bare Bones, and a single 'finit' doesn't even begin to touch on anything else that is needed for proper FPU support. - quok 19:13, 29 September 2009 (UTC)

Disk image

Why does this tutorial still use the kernel 200+18 method of loading? Wouldn't it be better to teach how to create a FAT/ext2 GrUB boot disk?, hence simplifying debugging (and allowing the same code to be expanded to load multiboot modules, and be accessed by the kernel)

People may not want to implement either of these file systems. They may not even want file systems at all. I find the current approach to be more general. --Love4boobies 01:06, 27 November 2010 (UTC)

Linkage

Is everyone comfortable with switching to external linkage rather than pushing things on the stack and then picking them up as arguments? The current way seems less natural, less readable, and is dependent on the calling convention. --Love4boobies 04:17, 15 May 2012 (CDT)

Back then, I thought it a good idea to show how stuff pushed by ASM can be popped by C. It was also closer to the example code provided by GRUB. But that was back when there was no x64 calling convention. In that light, I think external linkage would be better today. But then, try to make sure that you make the chance in all "Bare Bones" articles. We should strive to have them so things as similar as possible, the only differences being those demanded by the language. -- Solar 07:21, 15 May 2012 (CDT)

I have updated the C and C++ tutorials but I'd rather someone else take care of the Pascal and FreeBasic tutorials. It's been about 10 years since I've last used Pascal and FreeBasic I do not know at all. --Love4boobies 05:06, 28 May 2012 (CDT)

Stack top & bottom

As far as I know, bottom of the stack is were the first element is added. In case of x86, it is the highest address. Compare with current content:

1. Currently the stack pointer register (esp) points at anything and using it may
2. cause massive harm. Instead, we'll provide our own stack. We will allocate
3. room for a small temporary stack by creating a symbol at the bottom of it,
4. then allocating 16384 bytes for it, and finally creating a symbol at the top.

.section .bootstrap_stack, "aw", @nobits stack_bottom: .skip 16384 # 16 KiB stack_top:

I think all these occurrences of words bottom and top should be swapped. Do I miss something?

Comment style

I've changed the commenting style from the old # ones to the new C-style ones using /* and */, hopefully this is OK, I thought it was a good idea since the # style is deprecated and is used to override line number / file name when errors are reported by the assembler. That said, if people can give a good reason as to why it should be changed back, by all means, go ahead, I'm just trying to help avoid headaches in the future. Also, I used my own commenting style (a single /* and */ before the first line and after the last line of a comment block), but I know people like other styles, so if you really feel strongly about one and think it helps readability, go ahead and use that. -- Mikumiku747 05:10, 19 July 2017 (CDT)

Loading at 2M

A change was recently made to this article to switch the load address from 1M to 2M. This was based on the change author's real-world experiences with UEFI systems that did not mark the 1M region as available.

The change author's experience was not unique. Grub developers encountered the same problem, and added a feature to Multiboot2 specifically to address it: https://git.savannah.gnu.org/cgit/grub.git/commit/grub-core/loader/multiboot_mbi2.c?id=a620876e3b32e4ea0c9a7b3541fcb9a4dd4fb9eb

As the code in the barebones is not affected by this load offset, we should keep the updated 2M address. --klange 22:08, 11 November 2023 (CST)