On 2010/03/25 16:39, "Sebastian Andrzej Siewior" <sebast...@breakpoint.cc> wrote:
> * Moffett, Kyle D | 2010-03-24 19:28:06 [-0500]: >> The e500v1 was never very popular and all of the available parts today >> support double-precision floating point GPRS. With that said, I'm actually >> not sure if my current compiler is built properly to enable use of the >> double instructions. If it's not, that's going to be an essential part of >> my "rebuild the world with whatever arch name the dpkg maintainers want" >> project. > It is not enabled by default. You have to add -mfloat-gprs=double to > gcc. So it is required to patch the gcc to get this by default I thing. > I haven't look into this. Actually, according to this bugreport: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42007 We can just use --enable-e500-double when building (recent?) GCC. I guess I'll have to go rebuild the world again... :-\ This will be maybe the 4th time... *sigh* At least I still have all the source repositories with the cross-compile bugfixes! > The e200z6 go up to 300Mhz but I did not find anything that fast. So > there are probably glad to have everything precompiled. > I've been looking at MPC5566 and MPC5668G and they don't have anything > what coould be used as external storage (MMC/ATA/SATA and so on). They > don't seem to have a lot of flash either. So they probably run just > their application and nothing else. Unlikely that firefox mattars :) >> Yeah... IMNSHO it should be either "e500" or "e500v2" just to keep it from >> being so dang hard to type. Hopefully we've provided enough information so >> the dpkg devs can pick something and we can get on with the official port? > > powerpc_e500v2 would make it clear but it is a lot of typing. So right > now I would go e500v2 I guess. Ok, so hopefully we can all agree on "e500v2"? That's the name I'm going to go ahead and use in my newest build-cycle. For reference, I've included a summary of the rationale behind the suggestion: * The only chipset families that support "SPE" instructions are: * PowerPC e200 * PowerPC e500v1 * PowerPC e500v2 * The incompatibility between various SPE-capable CPUs mean that an arch spec of "spe" or "powerpcspe" is probably insufficiently descriptive. * The "e200" processor series is an automotive processor and has insufficient storage to run even something like Emdebian Crush, let alone to be able to build anything on its own. It should therefore be excluded from our discussion. This means we just care about e500v{1,2} cores. * Freescale has indicated that they will not be building any more chipset families including the SPE instructions, so we don't have to worry about any newer chipset families. * We can't tell exactly how common or uncommon the e500v1 chipsets are because Freescale's chipset comparison tables all just say "e500" without referring to the version. As a result, we should probably be safe rather than sorry and refer to the version in the arch name (IE: e500v1/e500v2). * We should just call it just "e500v2": * Sufficiently descriptive of the hardware architecture * Shorter and easier to type in commands (of which there are a lot) * Similar situation to "lpia" (which is not called "i386lpia") The "easier-to-type" reason is especially applicable if we do a uclibc port, as the name "uclibc-linux-powerpce500" is much more of a pain to type out repeatedly than "uclibc-linux-e500". Is there anything I left out? >> Once I get an e500 board up and running I'm dropping the cross-compiler >> package and icecc on all of those systems. I'll then replace /usr/bin/gcc >> and /usr/bin/g++ on the e500 board with versions that call "icecc" or >> "distcc" or whatever as "powerpc-linux-gnuspe-{gcc,g++}". That should speed >> up my build times considerably by sending a lot of the build jobs across >> gigabit to the beefy servers. > That still looks like a cross build and you may want look at [0]. As I > said, I've been there :) The difference between a regular cross-compile and an icecc/distcc cross-buildd is that all the ./configure shell-script madness and some of the preprocessor crap is run *entirely* on the target system, then the preprocessed code is shipped across the network to a big beefy x86 box for building. The environment is indistinguishable from a native build. (except for the fact that things build a lot faster) So even a relatively wimpy 1GHz dual-core system can keep 8-16 cores worth of beefy x86 systems busy, especially if it's ugly template-heavy C++ code or something else very CPU intensive to compile. The downside is that the shell scripts, preprocessor, and linker all need to be run on the target board, but that's still way better than doing the whole build there. Cheers, Kyle Moffett -- Kyle Moffett eXMeritus Software Integrated Intelligence The Boeing Company (703) 764-0925 (703) 832-0657 (fax) kyle.d.moff...@boeing.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
