<xiangfu>
which version you using in your nanonote now?
<unclouded>
rootfs is the latest
<unclouded>
kernel is still from December
<xiangfu>
can you give me the output of 'wget --version',
<unclouded>
that's when I run from MMC, which I do most of the time
<unclouded>
NAND has latest kernel and rootfs and works fine
<unclouded>
wget: unrecognized option `--version'
<unclouded>
looks like busybox is handling wget
<xiangfu>
thanks. can you make sure it. ?
<unclouded>
although I have built my own busybox so the busybox package might have been mangled to include wget whether the release version does or not
<unclouded>
sure.  my NAND is pristine, so I'll boot that and do the test there instead
<xiangfu>
thanks.
<unclouded>
different result.  I must have elected for busybox to include wget when I rebuilt it
<unclouded>
NAND says GNU Wget 1.12
<xiangfu>
unclouded: ok. what about ` wget --version | grep iri`
<unclouded>
simply says "-iri"
<unclouded>
nothing else
<xiangfu>
ok.
<unclouded>
would you like me to do any other tests on the NAND or can I boot back to MMC?
<xiangfu>
maybe the libidn is build after 'wget' build. that is why 'wget' not detect the libidn, but recently the packages build order changed,
<xiangfu>
unclouded: thanks. just back to MMC, '-iri' is enough :)
<xiangfu>
do you have account on downloads.qi-hardware.com?
<xiangfu>
real user in server?
<unclouded>
don't think so.  I have two Qi accounts: wiki and projects.  it's not either of those is it?
<xiangfu>
unclouded: ok. just send your ssh public key to me. I will setup account in downloads.qi-hardware.com
<unclouded>
the key is on its way to you now
<xiangfu>
unclouded: just ssh to downloads.qi-hardware. I setup a symlink in your home folder name 'people.unclouded' point to downloads.qi-hardware.com/people/unclouded/
<xiangfu>
wolfspraul: I found the folder under people/ is all www-data.www-data, only my folder is xiangfu.xiangfu, I always using 'scp' to copy files to downloads.qi-hardware.com, should I also using 'www-data'?
<wolfspraul>
don't know, I doubt there is much difference
<xiangfu>
unclouded: some feedback, if install both busybox man and your man-tiny, by default it's busybox, since the /sbin/ at a front of /usr/bin, Â
<unclouded>
that's pretty cool.  so packages can patch themselves over the busybox versions and then restore the busybox version if the extended package is removed?
<xiangfu>
unclouded: another thing, you may also want re-package 'manpages-dev_3.27-1_all.deb' to openwrt package.
<xiangfu>
:)
<unclouded>
that would make it easier for people to get the dev man pages on to the NanoNote for sure.  will add to list
<unclouded>
I couldn't find an upstream tarball for manpages-dev.  I think the collection actually originates at Debian
<xiangfu>
unclouded: ok.
<xiangfu>
then we can just download the deb package. and then write 'define Package/manpagers-dev/postinst  opkg isntall manpages.deb'
<kyak>
it would be nice to have some openwrt hack to be able to generate these *-dev packages automagically
<kyak>
just having a look at libsdl-dev by Neil.. everything is already there in build root, it's just a matter of copying of headers/libs/man pages
<kyak>
xMff: do you think it is possible to do somehow?
<xiangfu>
kyak: include $(INCLUDE_DIR)/man.mk ?
<xiangfu>
then add  CONFIG_MANPAGE ?
<xiangfu>
maybe no man.mk, just CONFIG_MANPAGE.
<kyak>
xiangfu: yes, maybe some global flag whether to include manpages/dev libs or not.. But i was thinking about separate packages for that
<xiangfu>
kyak: you mean every package like:Â Â wget, wget-dev?
<kyak>
maybe, if this flag is set, then build system will generate according separate pacakges..
<kyak>
yeah: wget, wget-dev, wget-manpages
<kyak>
i think it's done in lime like that
<kyak>
and all localization files are also splitted
<kyak>
like wget-locales-ru
<xiangfu>
not sure if OpenWrt users will like wget-dev, wget-manpages.
<kyak>
openwrt users won't need it, for sure
<kyak>
so they won't set the flag :)
<xiangfu>
kyak: another idea is , after all package compiled,  search all manpages in build_dir/... then create a package for all package man page :)
<kyak>
that would be a lot of information i think..
<kyak>
and i'm not even sure opkg running on Ben is capable of isntalling it
<kyak>
it will run out of memory, and then diskspace :)
<kyak>
another option is just to create there -dev and -man packages by hand, when necessary
<kyak>
just like Neil did
<kyak>
someone need to develop ncurses app on Ben? let's package ncurses-dev
<xiangfu>
my system is 40M /usr/share/man
<kyak>
mine is 63M :)
<xiangfu>
kyak: then the package-dev.mk is better.
<wolfspraul>
one day we need to do the 'next big repartitioning'
<kyak>
xiangfu: so this package-dev.mk will be a helper to package -dev and -man packages?
<kyak>
and magic will happen there?
<xiangfu>
wolfspraul: yes. we should thinking about it when we start switch to trunk I guess.
<xiangfu>
kyak: (package-dev.mk) I guess so.
<xiangfu>
kyak: something like rewrite 'Build/Compile/Default' , just an idea.
<xiangfu>
kyak: for example the cmake.mk.
<xiangfu>
kyak: hmm... maybe not. then we need change so many packages. that is not good
<unclouded>
will the size of the man pages matter much?  only those who wish to write C on the NanoNote would install a lot of -dev packages
<unclouded>
I was thinking the -dev packages could include the man pages ( no need for a seperate -man package) although that would waste disc space for a C developer who wants to read all their documentation in HTML
<unclouded>
but how likely is that?  and just how much space would the man pages consume?
<kyak>
hm
<kyak>
the total size of all manpages under build_dir is 6293699 bytes
<kyak>
but it might be due to the fact that most packages are not confgiured to generate manpages
<kyak>
i also wonder if i calculate correctly: find ~/openwrt-xburst.full_system/build_dir -name "*.man" -printf %s+ | sed 's/+$/\n/g' | bc -l
<kyak>
yeah, the assumption that manpages are named as "*.man" is not correct :)
<kyak>
-regex ".*\.man\|.*\.[1-9]" seems better
<kyak>
but then, it accounts for uncompressed man pages
<kyak>
he-he, and also some libs :)
<unclouded>
I would have expected man pages to compress well but the SDL ones only went from about 720K to 680K or something.  not much compression
<xMff>
kyak: yes, I think so
<xMff>
kyak: with a bit of work
<kyak>
xMff: what is your idea?
<xMff>
hijack Build/InstallDev somehow
<kyak>
hm.. so not even necessary to create additional makefiles in include/ and modify package Makefiles
<xMff>
yeah
<xMff>
since InstallDev typically installs what a -dev package would contain
<kyak>
exactly..
<xMff>
and its always relative
<xMff>
target path is passed as $(1)
<xMff>
not coded in the define
<xMff>
but its just a crazy idea for now
<xMff>
one has to dig through rules.mk, include/package*.mk and package/Makefile
<xMff>
to implement it
<xMff>
or to find out howto create corresponding -dev packages "out if thin air"
<kyak>
so it's not so simple after all..
<xMff>
well, its advanced makefile changes
<xMff>
but they  have to be done once only
<xMff>
not for each package
<xMff>
ok
<xMff>
the BuildPackage macro should be expanded
<xMff>
problem is when multiple binary packages share one source bundle
<xMff>
how do you name the -dev package?
<kyak>
binaries are usually separated from libraries?
<kyak>
like, curl and libcurl and libcurl-dev
<kyak>
but all build from the same tarball
<xMff>
right
<xMff>
and progrqammatically you can't decide whether it should be curl-dev or libcurl-dev without additional hints
<xMff>
you could only take the source package name and append -dev
<xMff>
which would be "curl-dev" in this case
<xMff>
or "glib2-dev" for libglib2
<kyak>
so you are saying that we can only peek at PKG_NAME
<xMff>
yes, more or less
<kyak>
maybe just prepend "lib" to the name
<xMff>
because source:ipk relation is 1:n
<kyak>
that would be a more or less correct guess
<xMff>
not sure
<xMff>
for example libsocks
<kyak>
having it as $(PKG_NAME)-dev is not so bad after all
<xMff>
the source is called dante
<xMff>
the dev package would be libdante-dev
<kyak>
though confusing :)
<xMff>
which makes no sense
<kyak>
maybe an argument to InstallDev to override that?
<xMff>
I fear nobody is going to maintain that
<kyak>
there won't be a lot of packages with confusing names
<xMff>
the extra argument I mean
<xMff>
we can consider it
<xMff>
something like  PKG_DEV_NAME
<xMff>
with fallback to $(PKG_NAME)-dev
<kyak>
then if someone decides that he is not happy with libdante-dev, he would add that PKG_DEV_NAME into makefile..
<xMff>
however I would not add the lib by default
<xMff>
that would be liblibtorrent-dev then :P
<kyak>
yeah..
<kyak>
exactly what i was going to say :)
<kyak>
though it can be considered
<xMff>
thats details after the actual implementation is there
<kyak>
are you interested in implementing this for openwrt? I fear i'm not capable, deep knowledge of openwrt internals is required
<xMff>
I'll take a stab at it
<kyak>
nice! :) call me anytime you need a hand at testing. .that's the best i can do
<xMff>
interesting
<xMff>
apparently one can overlay package makefiles
<wpwrak>
DocScrutinizer: hmm, should shorting an antenna to ground be safe or could this damage amplifier/balun ? considering that all the power that goes into the antenna should also leave this way, i would expect that it's safe. but i'm not sure if i can trust this theory ;-)
<ron_>
wpwrak have you heard any progress/status re: SMT run for the ATben and ATusb?
<wpwrak>
rjeffries: only that tuxbrain said last week that he'd make sure he'll set a day aside for going through the testing process this week.
<Jay7>
wpwrak: kexecboot.org
<Jay7>
whitequark: nice project :)
<wpwrak>
Jay7: ah, kinda obvious, in retrospect ;-) thanks !
<Jay7>
wpwrak: np :) what is context behind that question? ;)
<wpwrak>
Jay7: ah, there's a discussion of boot loaders on heise.de, and i wanted to mention one active project using a kexec-based boot loader
<DocScrutinizer>
wpwrak: depending on amp/tx, band, antenna, point of shortening it, you can create a SWR that's so abysmal that it blows your TX power amp. Not on <500mW TX pwr of course
<Jay7>
wpwrak: seems we (kexecboot) are last active project :)
<Jay7>
qi-bootmenu is stalled
<wpwrak>
DocScrutinizer: i have 2 mW ;-) safe enough then ?
<qi-bot>
[commit] Werner Almesberger: prod/doc/analysis.html: more material on checking the supply voltages http://qi-hw.com/p/ben-wpan/47b710d
<qi-bot>
[commit] Werner Almesberger: atusb: varistor Vdc was off by 100 mV; made it clearer that we use Vdc, not Vb http://qi-hw.com/p/ben-wpan/926ed26
<methril_work>
wpwrak, i'm almost going to FISL, do you have a MMOne?
<wpwrak>
methril_work: no, just a bunch of bens (and an avt2)
<methril_work>
ok
<methril_work>
i've my ben, and a MMOne
<wpwrak>
methril_work: rejon said he'll bring an mm1 to fisl
<methril_work>
rejon is going to FISL!! this is new to me :)
<wpwrak>
i need to clean up ubb-vga a little. would be nice to do the presentation with my ben ;-)
<methril_work>
how many ubb's do you have?
<rejon>
yeah, i'll be there
<methril_work>
i would like to buy 1 or two :)
<rejon>
i'm catching up today
<rejon>
excellent!
<wpwrak>
methril_work: yeah, i could part with one or two :)
<methril_work>
we'll try to pass brz taxes ;)
<wpwrak>
they still have RA taxes on them. but they're only about half of yours :)
<wpwrak>
roh: using ieee 802.15.4 for domotics. nice :)
<wpwrak>
roh: the next step should be to combine energy harvesting with all this ;-)
<roh>
not that neccessary
<roh>
most energy is eaten by displays not wifi or other radios
<wpwrak>
roh: hey, smart lighting that doesn't need a power supply ? don't you think that would sell like crazy ? ;-)
<lunavorax_mini>
I came up to the conclusion that the Raspberry Pi was a total faillure from start.
<wpwrak>
;-))
<lunavorax_mini>
Poor kids need a ZX-Spec desing-like computer, small keyboard (with normal keys, not rubber ;) ) and composite out for video and SD card slot for storage (plus some USB in for devices) and that's IT. No wireless crap, no extra stuff, only maybe a mono speaker or audio in + audio out.
<wpwrak>
lunavorax_mini: lekernel will be happy to read this :)
<lunavorax_mini>
imho, I'm not a computer specialist/designer
<lunavorax_mini>
I think some kids should start with Python or other high level language first
<lunavorax_mini>
I don't know much about Lua or Ruby.
<wpwrak>
bah. i started with the ti-57. 50 program steps. 10 variables. no persistent storage. all those friendly languages will just spoil them :)
<lunavorax_mini>
Yeah I don't know
<lunavorax_mini>
I feel stupid when I heard someone saying "I was programming in ASM at 13yrs old"
<lunavorax_mini>
And I still can't make a functionnal (and interesting) C program.
<mth>
I was programming in asm at 11 years old ;)Â Â although I wasn't very good back then
<mth>
I think I was about 15 before I actually could do useful things in asm
<wpwrak>
bah, at 11, i was designing my own computer :) (not that it would have worked ... i hadn't quite grasped the concept behind the R in "RAM" back then)
<lunavorax_mini>
Oh come on guys, now how should I feel ? :(
<wpwrak>
mth: four years of nothing but frustrating failure ? that's a rough childhood
<mth>
wpwrak: no, I went back to using BASIC in the mean time
<mth>
the main problem was that I had an asm book that wasn't written for beginners
<mth>
back then I wanted to learn asm because BASIC was really slow (interpreted on Z80)
<mth>
I don't know how it is for today's young
<lunavorax_mini>
Well I think I can answer
<lunavorax_mini>
And that's why I was defending the use of Python as it is simple to understand for a beginner and not that slow for simple things.
<lunavorax_mini>
(still I am planning to learn asm this summer)
<mth>
I do know that people from the Informatics Olympiad were trying to teach me a LISP-like Logo dialect with little success
<mth>
although that was more because of the weird structure editor rather than because of the language itself
<lunavorax_mini>
Haven't you forgot a ) ? ;)
<mth>
ah no, it was derived from Scheme, not LISP
<mth>
well, it is LISP-like
<Jay7>
I was programming ASM about 15 years old
<Jay7>
because I had zx spectrum :)
<Jay7>
like mth :)
<mth>
I guess the structure editor was designed to avoid parenthesis problems, but I couldn't get over the fact that the cursor would move through the program tree rather than just going up/down/left/right one position
<mth>
Jay7: actually MSX for me, but pretty similar hardware
<mth>
my first attempt at learning C also failed, I tried learning it from a book during a holiday (no laptop in that time, so holiday meant a few weeks without a computer)
<mth>
I think I don't learn from books very well, I have to be able to try things out
<mth>
lunavorax_mini: MIPS asm would be a good candidate then, it's much more elegant than x86
<wpwrak>
mth: naw, VAX assembler would be so much better. nothing illustrates better where the complexity in CISC lies than a little MOVC5 or a POLYH ;-)
<lunavorax_mini>
mth, actually, I'm aiming at learning x86 asm. I need it in order to understand disassembly of some x86 software I want to try to reverse-engineer
<lunavorax_mini>
In the other hand, I have 3 of the 4 only existing books about Z80 asm :)
<lunavorax_mini>
I'm also aiming to learn it at some point, I have a lot of Z80 devices here (gameboy, ti-83, VG5000, ZX-Spec)
<lunavorax_mini>
only existing French* books
<mth>
if you've never done asm before, Z80 might be a good way to learn
<mth>
it's CISC, but not as complex as x86
<graphitemaster>
the cool part about asm is you only need to know the basic fundementals of it, then you can plug in any type of instruction assuming the hardware supports it and it'll work
<graphitemaster>
most instruction sets are highly documents and can be found with a small google search.
<graphitemaster>
*documented
<lunavorax_mini>
mth, CISC ?
<mth>
complex instruction set computing
<mth>
as opposed to RISC
<mth>
in RISC instructions do very little work and are highly orthogonal
<lunavorax_mini>
graphitemaster, yeah I heard someone saying to me "I only know the instruction set and I can do whatever I want". Also a University teacher told me "I don't know any language that is simpler than asm"
<mth>
while in CISC instructions do more work and are specialized
<mth>
for example, on Z80 there is the DJNZ instruction, which does "decrement B, jump if non-zero" in one instruction
<graphitemaster>
RISC instructions are no good for anything but battery life and embedded platforms, with exception to ARMv6 which I think is the only sane RISC route these days.
<lunavorax_mini>
Battery life ? That means ultra precise programming then, no ?
<mth>
graphitemaster: RISC might be easier for compilers to generate code for as well
<mth>
since the registers are interchangeable
<graphitemaster>
well I would never reccomend a CISC set for an embedded platform because it's just too complex and pointless in that type of situation
<mth>
when writing Z80 asm, good register allocation is probably the most important factor for performance
<graphitemaster>
well I think the worst is RISC does a fine job at splitstreaming instructions to a fair common selection, but does a horrible job at doing a select task in the fewest instructions possible
<mth>
most C compilers that target Z80 will pass arguments via the stack rather than registers, making the generated code a lot slower than hand-written asm
<graphitemaster>
with exception to ARMv6
<mth>
maybe not the actual stack via SP, but some kind of program-managed stack using IX or IY
<graphitemaster>
I think my biggest issue is most of the older RISC chips has no microcode so they where forced down the pipeline into logical control singnals for the datapaths _directly_ from each instruction bit.  Now take a rather obstruisve program that requires a lot of decodes and the branches will slow down and take FOREVER to resolve and you ruin performance not for the whole program but everything
<graphitemaster>
I think ARM was the chip that actually broke away from this method which is primarly the reason I like ARM chips these days.
<mth>
I haven't written any ARM asm yet
<mth>
last thing I did in asm was MMX and SSE versions of video scaling algorithms
<graphitemaster>
MMX is pretty useless
<graphitemaster>
it's deprecated in all newer generation AMD chips
<mth>
this was over 5 years ago though :)
<graphitemaster>
well that acounts for something then :)
<graphitemaster>
I have worked on ARM code before, I find it a delight to work with it's well documented too.
<mth>
today I probably wouldn't bother with MMX indeed and go straight for SSE2 or GLSL or OpenCL
<graphitemaster>
SSE4 is pretty suboptimal
<graphitemaster>
GLSL again does the card support shaders?
<graphitemaster>
5 years ago ARB was really the only choice :)
<mth>
most cards do nowadays
<graphitemaster>
and ARB was not all that different from ASM the syntax was but the thinking was and still is the same.
<graphitemaster>
erm thinking was the same the syntax was different *
<mth>
actually my first GLSL shaders are from 2006 :)
<mth>
but back then it would only work on certain cards
<mth>
especially Intel didn't support OpenGL 2.0 for a long time
<graphitemaster>
Intel still doesn't support half of GL :P
<graphitemaster>
I've herd cases where you can get better gfx using llvmpipe over Intel then using the native Intel GMA crap :P
<graphitemaster>
software rasterization at it's finest :)
<Jay7>
remember LDIR instruction
<Jay7>
was very useful for graphics :)
<mth>
on MSX VRAM was not shared with the Z80, so you had to use OTIR instead
<graphitemaster>
there where quickerways then using LDI LDIR
<graphitemaster>
usually save the stack pointer, load the hl register pair with zero.  massive loop pushing HL onto the stack, then the stack moves up screen and down through memory and in the process and clears the screen :)
<roh>
meh
<roh>
you guys make me feel old.
<graphitemaster>
I'm 16 years old :P
<roh>
will be 30 in august and its evil to hear stuff you did when it was new and fancy
<graphitemaster>
I own a ZX Spectrum I've played with Z80 before :P
<roh>
my 2 cents: ignore the current seperation of 'X'PU(s)
<mth>
roh: I'm 35, these are stories from the good old days ;)
<roh>
there will be cpus which just have N cores and units which will look remarkably like some merge of cpu, gpu, crypto-accel, dsp and maybe we will get even some pld-esque units
<roh>
all that syncronisation stuff just eats away most of the gain by offloading anyways.
<graphitemaster>
I think what would be neat is if someone interlocked varations of CPUS from mixed CISC it mixes RISC then made a common interface that could translate op code and offload work on each cpu equally
<mth>
roh: but will it have a shared memory like current CPUs or local memories like the Cell?
<roh>
e.g. dma not being faster than simple loops etc. (cloggs memory bus, set up partially complex and needed too often etc)
<graphitemaster>
generally you can just plugin anything into this core and as many as you wanted and it would work
<roh>
mth: modern computers are numa cubes anyways. atleast amd based ones since... well.. nearly 10 years now
<roh>
means every 'cpu' has its own local memory, maybe shared by 2 or more local cores, and there is a shitload of bandwith with low latency to 'other stuff' .. maybe cpus, maybe io (mostly differs in cache coherency)
<roh>
also i think that these nice products like cell will vanish. their special feats will become mainstream. but specialized cpus like that just make no sense economically
<Jay7>
is 32 :)
<roh>
thus.. my bet is on 'we will have fun with new instructions' and lots of cores.
<wpwrak>
roh: agreed on xPUs. those specialized co-processors come and go. they always end up being absorbed into the principal core sooner or later.
<roh>
wpwrak: if they make sense, yes
<mth>
what will we use to program them though?
<roh>
mth: more uniform than this gpu, dsp, cpu madness right now (which needs specialized tools and knowledge for every sub-arch)
<roh>
basically: think 'gcc' (replace with clang or what you wish when they finally make it complete)
<mth>
I don't know C + threads is going to work
<mth>
threads are horrible things anyway
<roh>
mth: sure. have a better idea?
<mth>
not really, that's the problem
<graphitemaster>
forking
<mth>
GLSL parallizes very well, because it's basically a functional language with a C-like syntax
<mth>
but not every algorithm is easy to express in GLSL
<mth>
*parallellizes (?)
<roh>
my point is: try syncing 3 of the current cores in a pipeline working on some data... then imagine the cpu is also running a multitasking os with preemtion. then imagine every of these cores using a different compiler from a different company... can you imagine that c-threads somehow sound quite nice compared to the hell you will be in now?
<roh>
its all nice and shiny as long as you dont need to glue 2 vendor-sdks into one project
<roh>
also lots of stuff mis-optimized (depending on usecase) isnt in your way anymore. e.g. writing stuff to gpu memory is fast (optimized) .. try reading something back to the cpu memory... takes aeons
<roh>
compared to a write. has been that way since agp times. so sometimes it even makes sense to do steps on the cpu instead of using the fast way into gpu mem, do some op there (do sync), fetch slowly, do next op which the cpu can but the gpu is too stupid for.
<mth>
iirc AGP was very asymmertrical with the bandwidth, but on PCI Express the direction shouldn't make much of a difference
<roh>
so in the end one ends up with optimizing the own usecase, which could mean: do more steps on the cpu even if the gpu is faster not not get your advantage eaten up by slowness in unoptimized memory transfers (which one cannot speed up)
<roh>
mth: pci-e still is multiple times slower than memory access or a hypertransport link
<mth>
yes, but CPU->VRAM and VRAM->CPU are both about equally slow
<roh>
my point is: nowadays gpus arent much more like 5-10 years ago. its mostly a block of shaders with some minimal memory copying logic and a display-readout and fast memory. add the shaders and the memory interface bandwith to the main cpu and you dont loose anything, you only gain
<mth>
but it's true that fast processing is useless if you can't get the data in/out in time
<roh>
mth: gpus are optimized for gaming, not your usecase neccessarily.
<roh>
e.g. all the video and multimedia blitting units are gone. because you can also program a shader to do colorspace conversion
<roh>
but when it comes to e.g. implementing complex stuff which isnt just doing fast math but assembling packets, shaders suck. not built for that. so compressing data or so isnt their best deed. they can do some steps but the gruntwork usually is done in specialized hw or the cpu and not a programmed shader.
<roh>
amd is on the right way there. lets hope they dont die from intels constant nagging
<roh>
and keep supporting free drivers.
<mth>
I hope that at some point driver support will just be an LLVM backend for a new chip rather than a full driver
<roh>
i hope we dont need new archs that often
<roh>
and that llvm gains more working backends. last time i tried it couldnt even generate properly working arm code, not speaking of booting kernels
<mth>
Apple allows LLVM-compiled apps to be submitted, so it must work most of the time nowadays
<mth>
I recently managed to compile openMSX (pretty complex C++ code, crashes quite a few GCC versions) with Clang++ and libcxx on x86_64
<mth>
so it's starting to become useful in production
<roh>
is there a avr backend?
<mth>
afaik only x86, x86_64 and ARM are mature backends, the others are experimental
<mth>
I don't know about AVR support; MIPS support exists but may or may not be usable
<roh>
meh. that needs to change. multi-arch is the most important feat of gcc.
<roh>
atleast to me. compilers are annoying enough that i dont want more than one kind to know personally ;)
<roh>
well.. in the end ist all just a fancy macroassembler, so if you do nice code, the backend shouldnt matter that much nowadays
<mth>
they have reduced the arch-specific code to a minimum, so that should help in getting more archs supported
<mth>
I've heard people complain about GCC support for Alpha, so it's not paradise either
<roh>
alpha is dead. really dead for some time now
<roh>
all thats nice in there went into x86-64 anyways. and into the design of amd cpus
<roh>
thats where hypertransport and the numa concept come from.
<mth>
yep
<roh>
hppa is also dead. i think mostly mips arm x86-64, x86 and some mcu platforms are important right now
<roh>
the problem is the sheer number. msp430, avr, infineon has its own 16bit arch... the hitachi stuff.. renesas...  etc
<roh>
avr is to inprecise. there are 8bit and now also 32bit ones (different arch, avr32)