Talk:Multiboot1 Bare Bones: Difference between revisions

m
Mintsuki moved page Talk:Bare Bones to Talk:Multiboot1 Bare Bones: This name better suits what the page is about.
m (Talk:Bare bones moved to Talk:Bare Bones: Capitalisation as per manual of style)
m (Mintsuki moved page Talk:Bare Bones to Talk:Multiboot1 Bare Bones: This name better suits what the page is about.)
 
(15 intermediate revisions by 10 users not shown)
Line 1:
== Renaming ==
fixed minor mistake-meshounah
 
:Depending on the compiler, leading underscores are either required or wrong. Also, the summary field was designed for these messages - [[User:Combuster|Combuster]] 17:42, 11 August 2007 (CDT)
Shouldn't this page get renamed?
::We should add either <tt>-fleading-underscore</tt> or <tt>-fno-leading-underscore</tt> to the gcc command. I'd personally prefer <tt>-fno-leading-underscore</tt> and removing all underscores from the NASM and GAS code. Any opinions on the matter? -[[User:Jhawthorn|Jhawthorn]] 19:04, 15 August 2007 (CDT)
Because every other language's BareBone is called [Language Name] BareBone.
:::I'd go for suggesting that a [[GCC Cross-Compiler|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. - [[User:Combuster|Combuster]] 04:34, 17 August 2007 (CDT)
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.
[[User:Columbus|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. --[[User:Ajxs|Ajxs]] 23:59, 23 April 2017 (CDT)
 
== main -> kmain ==
Line 35 ⟶ 41:
 
::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. --[[User:Paxcoder|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. -- [[User:Mbrush|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 - [[User:Combuster|Combuster]] 17:42, 11 August 2007 (CDT)
::We should add either <tt>-fleading-underscore</tt> or <tt>-fno-leading-underscore</tt> to the gcc command. I'd personally prefer <tt>-fno-leading-underscore</tt> and removing all underscores from the NASM and GAS code. Any opinions on the matter? -[[User:Jhawthorn|Jhawthorn]] 19:04, 15 August 2007 (CDT)
:::I'd go for suggesting that a [[GCC Cross-Compiler|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. - [[User:Combuster|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? -- [[User:Solar|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. - [[User:Combuster|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. - [[User:Quok|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. --[[User:Love4boobies|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. --[[User:Love4boobies|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. -- [[User:Solar|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. --[[User:Love4boobies|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:
 
# Currently the stack pointer register (esp) points at anything and using it may
# cause massive harm. Instead, we'll provide our own stack. We will allocate
# room for a small temporary stack by creating a symbol at the '''bottom''' of it,
# 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. -- [[User:Mikumiku747|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. --[[User:Klange|klange]] 22:08, 11 November 2023 (CST)