NutPi DDE Targets?

I am considdering purchasing the NutPi suite, though I do have a couple of questions regarding the DDE.

Which compilers are included in this low cost version?
I would assume C, C++, and ObjAsm. Though does it include ABC, etc.

Is there any restriction to the compile targets with any of the included compilers?
Can it still produce object code for older versions of the ARM? Can it still produce 26bit compatable object code?
I ask these as I undersand that it will only run on the RPi, though I would like to compile for older targets, and RISC OS 3.5/3.6/3.71/4.xx/etc.

AIUI, the NutPi DDE is the full version, not cut down in any way, except it gives an error if you try to run it on anything but a Pi. It’ll still compile everything it did before, although obviously you’ll get a bit more oomph buying the full version and running it on a BeagleBoard.

“more oomph… on a BeagleBoard.” Has anyone done some compiler speed tests on the Pi?
How important is memory speed for a compiler?
The speed tests so far on the Pi have been very patchy and variable. It would be nice to have some independent tests.

How important is speed for a compiler? Really it just depends on how much you like or hate coffee. A slowish compiler lets you go and have a pee, tank up with another cuppa, get back and check the status before restarting it all after spotting the stupid missing flag. A fast compiler results in you sitting at a desk all day, rapidly going nuts as run after run finds a problem, you get stiff in places where you didn’t know you had places, dehydrate because you haven’t taken a break, and start to decompose because you haven’t even stopped for a shower in a week.

Slow systems have their uses.

I think it is a matter of scale. Three minutes is pretty bad, so let’s assume a reasonably competent tool set can do things at an average of 30s per thing (module, app, etc). Well, there’s more than 100 parts to RISC OS, add it up. ;-)

Having said that, the main time you’ll see the speed of the compiler are those “why doesn’t this damn thing work” – you know the ones: fiddle, compile, run, bang, fiddle, compile, run, bang…
…until you facepalm at 3.27am when you realise that there was some stupid niggle somewhere else and essentially you’ve been chasing phantoms, but you can’t smile yet because forty gallons of tea and other beverages wants out NOW.
Times like that, you’d really curse a slow compilation.

What software are you running on the BBxM? It sounds suspiciously as if you’re trying to run something which isn’t ARMv7 compatible. Remember, the Pi is only ARMv6, which means you can run a greater amount of software on it safely.

Also, I think the toolchain for building RISC OS still isn’t fully ARMv7 safe itself – the supplied grep binary is a notorious example. (When is anyone going to get around to fixing this? It can’t be that hard.)

Mostly stuff that I am writing that crashes RISC OS on the BBxM.

My first question would be – what libraries / compile options are you using?

I noticed my version of DeskLib crashes on the xM – I don’t plan to fix it until I have got myself the latest compiler because the code ought to be okay… However there are various code sequences to avoid – unaligned loads for starters. All the MOVS PC and LDMFD …^ as well.
What language are you using, and have you identified any problematic parts of the code yet? Is it your own or in a library?

I don’t know about ARMv8. I’m trying to use fairly generic 32bit safe code, so fingers crossed that there won’t be big problems ahead!

Also, I think the toolchain for building RISC OS still isn’t fully ARMv7 safe itself – the supplied grep binary is a notorious example. (When is anyone going to get around to fixing this? It can’t be that hard.)

I keep planning on fixing it… but then forget about it sometime between the time I post on the forums about it and the time I get home.

Re BBxM crashes: what sort of abort? ; at what address? ; and what were the registers at the abort?