OSDev.org

agree for the "inline assembly" page.

Rather pro-nasm for the long asm examples (i'd for sure make mistakes if i had to write AT&T and barely can check if the submitted gas code will be working)

I guess it could worth a poll ...

just found http://www.niksula.cs.hut.fi/~mtiihone/intel2gas/, a gas <-> nasm converter ... It probably still needs improvements (mainly boring regarding spaces, etc), but it looks to work quite well otherwise.

Poll created on the ASM syntax question.

Hmm ... looks like there's something wrong with URLs carrying a "~" symbol in the Wiki. On RalfBrown page, for instance, you cannot follow the "home page" link because the wiki wrongly translate domain.edu/~ralf/page.html into domain.edu/ralf/page.html ...

Any hint ?

Pype.Clicker wrote: On RalfBrown page, for instance, you cannot follow the "home page" link because the wiki wrongly translate domain.edu/~ralf/page.html into domain.edu/ralf/page.html ...

Any hint ?

The most common solution: use two

RalfBrown page fixed. Sandbox fixed too

Mimmic'ing User Archetypes, i've started a [url=http://www.osdev.org/osfaq2/index.php/What%20order%20should%20I%20make%20things%20in%3F]OSdever archetypes page on the FAQ. The purpose is to show how one could reach the 'milestone' he wishes safely and avoiding a dead-end after that milestone is reached. Help is welcome for Eleanore Semaphore and Nick Stacky ...

Dudes... I just found that our Wiki page "GCC Cross-Compiler" ranks *very* high on Google searches on the subject. (Like, #1 or #2, far ahead even of the "official" GCC Cross-Compiler FAQ...)

I also found that the vast majority of cross-compiler howto's (including the "official" FAQ) focus on one specific host system (like, "do an apt-get..."), one specific target, and ancient (2.*) GCC versions, usually combined with specialized build scripts that still leave the user in the dark about the process. Talk about the disadvantage of static HTML...

Now, having a core page that gets pushed in the face of anybody looking for information on GCC cross-compiling, I thought whether we should somewhat expand the scope of the page.

After all, at some point or another, most if not all of us here will want users to build cross-compilers (or to bootstrap native compilers) for our respective operating systems...

What do you think about extending the "GCC Cross-Compiler" page towards being a generic information source on the subject of cross-compiling? I mean, it would eat OS-FAQ ressources on an only losely related subject, but I think it would be a welcome effort indeed...

df?

what concerns me is that the page is already 3-sheet-long ... beware that adding extra (not OSdevers-specific) information may simply makes it harder to read...

My idea was to re-organize the page a bit, move some of the already existing information into subpages, and then extending on that.

this page seems to contain a lot of info that might suit the faq:
http://users.win.be/W0005997/gi.html

/ Christoffer

its a wiki, you can go to town and do whatever on the gcc cross comp page i really dont mind.

i like to think of it as trying to get th ebest possible information across to the reader.

hmm I was thinking, is it possible to change SandBox to TheSandBox or something, this would stop most of the spammers who know that 'SandBox' exists in most every wiki...

not sure how feasible it is tho.

Well, it's very easy to set up TheSandBox, and change all links to SandBox -> TheSandBox. Done in five minutes.

The one thing that makes SandBox special is the ability to "rake" it, i.e. reset it to the original contents. We haven't used that feature yet, and we could either do without or find the place in the PHP code that targets SandBox for this. (Should be a case of grep'n'edit.)

On the Inline Functions page, why does it use [tt]__inline__[/tt] instead of [tt]inline[/tt]? Is it because of the difference between Gnu C inlines and C99 inlines?

It's because basic C doesn't know inline, but GCC knows __inline__.