Tiny Core Extensions > TCE Talk

Compiler flags and semi-portable extensions for "newer" pcs?

(1/4) > >>

qopit:
The wiki page on creating extensions currently indicates that, for compatibility, the -march=i486 and -mtune=i686 options should be set.

This is obviously working very well for compatible extensions with Tiny Core, but I've been searching everywhere and can't find a good explanation of why those options were chosen (aside from it obviously working well!).  For example, why not just use -m32 instead, which seems more generic?  Is it that i486 provide some performance improvements over m32 (which seems to go back to support 386 instruction sets, per the docs), while also going back far enough to meet a minimum supportable hardware platform for Tiny Core?

Related to this, and assuming it is rooted in the minimum hw requirements, what if I want to make a portable TC extension for movement between my own pcs that can squeak out a bit more performance?  For example, I want to make a custom python extension (or even just a portable dir for frugal installs) that I can move around my servers that has presumably better performance than would be obtained with -march=i486 and -mtune=i686, when I am certain that all the machines/CPUs I will be running it on are < 5 years old.

I'm not looking to make this insanely complicated, just looking for a "better" set of compiler flags while remaining reasonably portable.  For example, I'm wary of running into compatibility issues with the support libraries needed for the python compilation.  To scope this, what I mean is that I'd ideally like to be able to stick with something similar to this simple python compilation chain, but with "modernized-but-still-portable" compiler flags:


--- Code: ---tce-load -wi compiletc bzip2-lib bzip2-dev openssl-1.0.0 openssl-1.0.0-dev sqlite3 sqlite3-dev ncurses ncurses-dev
export CFLAGS="-march=i486 -mtune=i686 -Os -pipe"
export CXXFLAGS="-march=i486 -mtune=i686 -Os -pipe"
export LDFLAGS="-Wl,-O1"
wget http://python.org/ftp/python/2.7.3/Python-2.7.3.tar.bz2
tar xjf Python-2.7.3.tar.bz2
cd Python-2.7.3
./configure --prefix=/mnt/sda1/python --enable-ipv6
make
make test
sudo make altinstall

--- End code ---

Since the support libs like bzip2 are presumably compiled with -march=i486 and -mtune=i686, does that lock in everything else down the chain to use those as well?  I'm out of my depth here, but do know that binary compatibility is a non-trivial issue.

Also - what if I wanted to port around 64 bit python (or other extension)?  I can't find any good information on best practices for making 64 bit extensions for TC.  I've got my 64-bit TC working (with core64.gz and vmlinuz64, which were tough enough to find already!).  It seems like -m64 would be a good and portable bet there, but don't really know.  Does -m64 overlap and eliminate the need for the -march and -mtune flags?

Rich:
Hi qopit
The  -march=  option dictates the minimum required processor required for the software to run.
The  -mtune=  option I'm less certain of. I've seen the following in some GCC documentation:

--- Quote ----march: Generate instructions for the machine type CPU-TYPE. Specifying -march=CPU-TYPE implies -mtune=CPU-TYPE.
--- End quote ---
And found the following at another site:

--- Quote ----mtune={cpu} : Tunes the binary for given cpu on x86 architecture. This means that the binary will still execute on a 386 (if it did in the first place), while also including optimization for the cpu supplied to the '-mtune=' switch.
--- End quote ---
Draw your own conclusions.
I don't think libraries will that have been compiled with the current settings will cause any trouble.
Can't comment on how to deal with 64 bit.

Juanito:
-m32 and -m64 let gcc know whether to compile 32-bit or 64-bit applications/libraries.

In core64, the kernel has been compiled 64-bit to allow the use of more than 4gb of ram, but core64 will not work with 64-bit applications/libraries as-is.

As regards optimising using different optimisations (see http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options), I'm not sure you'd see a big difference unless you were using something cpu-intensive and unless you recompiled the base and dependent libs with the same optimisations

qopit:
Thanks, guys.  I suppose the part that is bugging me is that it seems quite restrictive to limit the instruction set used to the 486 instruction set.  Presumably the large number of new instructions since i486 should add a significant performance increase for directly compiled code?

I definitely understand that for TC it is a good idea to limit to i486 so that older hardware can be brought back to life with TC.  What I'm after is figuring out what newer instruction set is further along the commonly supported timeline than i486 such that code compiled with that instruction set would be sure to run on CPUs built in the last 5 years.  That is certainly more suited to a gcc forum, I guess.  What would be awesome is a timeline of instructions sets, showing common Intel+AMD processors and what instruction sets they supported (ideally in gcc -march speak  :)).  I can't find such a beast, though.

Side note: While looking into the instruction set issue I found a great article on the instruction set war between Intel and AMD (and VIA).  It is worth a read/skim:
http://www.agner.org/optimize/blog/read.php?i=25

For the separate 64-bit aspect of my post... Juanito, what exactly did you mean by this:

--- Quote ---In core64, the kernel has been compiled 64-bit to allow the use of more than 4gb of ram, but core64 will not work with 64-bit applications/libraries as-is.
--- End quote ---

Does that mean that getting python to be able to access > 4GB of memory is not a simple task on core64?  I've certainly not been able to achieve it so far... straight compilation gave me a 32-bit python.  Adding CFLAGS=-m64 didn't work, because the gcc in compiletc.tcz doesn't have 64 bit support and fails immediately.  I don't see a gcc64.tcz, or a compiletc64.tcz, so now I wonder if I'll be able to run any 64-bit apps at all.  But that leaves me completely confused as to what core64 gets you, so my confusion must be more complete than just that :).  I obviously need to look into the 64 bit core in more detail, but have struggled with this quest so far.

qopit:
On the core64 thing... is it that core64 enables the OS to support processes that total up to more than 4 GB of RAM, but "as-is" we can only have 32-bit applications due to there only being a support suite of 32-bit libraries easily available?

As a totally crude/artificial example to paraphrase that: is it that core64 could support 3x 32-bit processes, each of which only has access to 4 GB of RAM?  While supporting 64-bit processes that can themselves access > 4GB of RAM would require a full 64-bit support chain of gcc, libs, etc?

I found a related thread with this statement:

--- Quote from: gerald_clark on April 03, 2012, 09:21:32 PM ---There are no 64 bit binaries or libraries.
User space is 32 bit.

--- End quote ---

and I'm shakily interpreting that as above.  I don't quite get the user space thing or how the 32-bit addressing inside a process would work (if I'm right in my understanding).  I'll need to read up on it.

This is throwing me back to the days of the "extended" vs "expanded" memory and the BS paging involved in accessing that <shudder>.  Is it similar?  I've not had to deal with memory management like this in a very long time and I've avoided the 32-bit/64-bit thing... the OS just makes memory available to me.  But I've not done any 64-bit development, so I'm now confused.

Navigation

[0] Message Index

[#] Next page

Go to full version