Talk:Multiboot1 Bare Bones

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)

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

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)