Pandora Compiling For Pandora (Tcc?)


ljones

Member
Joined
Aug 12, 2006
Messages
220
Hello all :) !

Now that I have my pandora (yay!) I'm now starting to wonder just how to compile programs for the pandora that already exist with source and what to use. I'm no programmer but there's at least one or two programs I'd like to compile for the pandora. I've not tried any of it yet but the thought did occur -- if anyone wants to compile on the pandora itself would it be a better idea to try to use tcc ( http://bellard.org/tcc/ ) instead of gcc? Maybe that would be better for the pandora and work faster?

Might be intresting to get bacon basic ( http://www.basic-converter.org/ ) going on the pandora!

ljones
 
"FAST! tcc generates x86 code. No byte code overhead. Compile, assemble and link several times faster than GCC."

That should probably answer your question.
 
Exophase said:
"FAST! tcc generates x86 code. No byte code overhead. Compile, assemble and link several times faster than GCC."

That should probably answer your question.


Ack! Oh well worth a try :-( . Wonder if there's anything else similar to it? GCC would be enormous!

ljones
 
Last edited by a moderator:
ljones said:
GCC would be enormous!
63 MB installed here, and it includes the C++ compiler.
It probably uses less than that much RAM when it's compiling, but it will also use some RAM to hold partially-compiled code. I can't say how it will perform with 256 MB, but compiling large programs might be very, very slow.

If you want something small and fast, get Google Go. It's not useful at all because there don't seem to be many libraries yet, but the compiler is ridiculously fast and I believe there is an ARM version.
 
Last edited by a moderator:
GCC should be fine for modestly sized programs, but if you try compiled C files that expand to tens of thousands of LOC then you'll run out of RAM fast. I've needed 1+GB to compile files like that.
 
Multiplex said:
Clang claims to be faster and use quite a bit less memory than GCC.

Targeting LLVM should have some other advantages too, seems like a good option.

This one is as old as dust but maybe someone will want to give it a compile anyway:

http://www.bebits.com/app/1501
 
Last edited by a moderator:
lulzfish: which packages have you got installed to get that C++ compiler onboard? I want to use the Pandora itself, with native compiler, to build some things .. has anyone figured out the package list to be installed yet? libstdc++-dev, gcc, and so on .. what else is there?

Are the -dev packages, with headers for things like SDL and GL ES, available natively? I remember a thread about this some 6 months ago, but I don't recall the conclusion for how we will be able to use the Pandora itself to do native builds.

I prefer to use an onboard compiler, personally, because it reduces a lot of fuss with cross-compiling and makes some ports of some things very easy ..
 
torpor said:
lulzfish: which packages have you got installed to get that C++ compiler onboard?
oh fuck, I should have been more specific.
I'm in the second batch. The installed size is for my Arch laptop. It's just the "gcc" package, but it also depends on binutils, libmpc, cloog-ppl, and libelf.
I don't know which Angstrom packages you'll need for g++, but it can't be much worse than the 63MB I have. Is ARM code bigger or smaller than x86?
 
Last edited by a moderator:
Slightly bigger unless it's using "thumb" instructions which is unlikely as not all instructions are available in the thumb set.

[edit] Little comparison here, only three samples, the ARM binaries are 7% to 15% bigger than the x86 binaries. http://www.brightsideofnews.com/news/2010/4/7/the-coming-war-arm-versus-x86.aspx?pageid=1
 
PhillipJ said:
Slightly bigger unless it's using "thumb" instructions which is unlikely as not all instructions are available in the thumb set.

[edit] Little comparison here, only three samples, the ARM binaries are 7% to 15% bigger than the x86 binaries. http://www.brightsid...6.aspx?pageid=1

IMO that comparison is out of date. If code density matters this much to you on Cortex-A8 you can use Thumb-2, which has all of the functionality of ARM and nearly all of the per-instruction expressivity while still providing much smaller code size; binaries in Thumb-2 generally run nearly as fast (within a few %). Thumb-2 was mainly rolled out for deeply embedded platforms where code has to fit on a small amount of cache, like the Cortex-M series. But it's still an option on A8 and A9.

For the record, the other usual arguments presented in that link are kind of inaccurate and cliche... it's getting a little off topic but I can't really hold back:

Number one: a "CISC" instruction set isn't automatically more expressive than a "RISC" one. Compared to ARM, x86 is optimized in all the wrong ways, and ARM is in many ways more powerful per-instruction, except for memory operands which only works well for the x86 archs that support it well; which granted does include Atom.

Number two: converting to "RISC" micro-ops internally is a trick that only really helps OoE throughout, and that's why Intel's in-order superscalar CPUs like Pentium 1 and, more recently, Atom, don't do this. Moreover, this still doesn't overcome the limitations of x86 which end up surfacing as a front-end bottleneck, which is actually relevant when decoding on x86 is so expensive. Especially for Atom which can "only" decode 8 bytes per cycle - on Cortex-A8 this is no different, but you're actually guaranteed to get two instructions out of that. If you use immediates greater than 1 byte or more modern instructions with lots of prefixes it'll quickly be easy to exhaust this. Without OoE and renaming the two-address instructions and limited register file hurt you more on Atom. Or at least his is the impression I get when hand scheduling ASM for it.

Number three: claiming that being an OoE CPU puts Cortex-A9 on footing with modern desktop x86 CPUs. Nope, those are still much wider. I've seen people claim that OoE increases performance 4x (and that's why Wii's CPU is actually stronger than XBox 360's and PS3's main PPC cores.. although clock for clock I'm sure it is much better)

Finally, hyperthreading can be good, but it's a double edged sword - on Atom having it on can actually hurt performance in single-threaded dominating situations because of increasing pressure on a starved BTB (Agner Fog has talked somewhat indepth on this).
 
Last edited by a moderator:
Ease up big fella! I linked that article because someone had directly compared ARM and x86 binary size. That is all. lulz and torpor were discussing how much space gcc would take up on Pandora but didn't have arm binaries to check.
Not that more up to date info isn't appreciated of course.
 
PhillipJ said:
Ease up big fella! I linked that article because someone had directly compared ARM and x86 binary size. That is all. lulz and torpor were discussing how much space gcc would take up on Pandora but didn't have arm binaries to check.
Not that more up to date info isn't appreciated of course.

Yesss, so if space matters to you, -mthumb is actually not an awful idea now.

Just be happy I chose to only comment on the first page, I have tons of other things I wish I could say about the article in general ;D None of it has anything to do with you of course, I'm not even shooting the messenger. That is, unless you dive in the way.
 
Last edited by a moderator:
Tons of things that would be worth reading for people who have primarily been developing for x86 devices and are now considering developing for ARM devices? Or just tons of clearing up misinformation that doesn't really apply to people who are not writing compilers?
 
PhillipJ said:
Tons of things that would be worth reading for people who have primarily been developing for x86 devices and are now considering developing for ARM devices? Or just tons of clearing up misinformation that doesn't really apply to people who are not writing compilers?

I dunno, maybe a little of both. Why are you pressing me on the relevance on things I haven't even said?
 
Last edited by a moderator:
Exophase said:
I dunno, maybe a little of both. Why are you pressing me on the relevance on things I haven't even said?
speculative execution?
 
Last edited by a moderator:
Back
Top