dpawson
Posts: 129
Joined: Mon Nov 14, 2011 5:05 pm
Contact: Website

Re: on board (the rpi) software tools.

Thu Nov 24, 2011 1:38 pm

Assume I'm running fedora or Ubuntu
on the rpi.

What C/assembler tools will be present/available please?
FOSS or paid, I'm curious generally.

Will it be the Gnu binutils as/ld/adb suite,
or some set of ARM tools?... Or something else?

Any information on this please?

Dave

asb
Forum Moderator
Forum Moderator
Posts: 853
Joined: Fri Sep 16, 2011 7:16 pm
Contact: Website

Re: on board (the rpi) software tools.

Thu Nov 24, 2011 1:56 pm

You won't be running Ubuntu on the Raspberry Pi (not a recent one anyway, they're targeting ARMv7+ only). You'd have the GNU toolchain by default.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23879
Joined: Sat Jul 30, 2011 7:41 pm

Re: on board (the rpi) software tools.

Thu Nov 24, 2011 2:03 pm

Any of the above - check the wiki for stuff I and others have already tried.

Even if not installed on the card when you get it, any of the usual GNU and other languages are only a quick download away....

Although Python and C/C++ (and Perl?) are expected to be on the card I think.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

dpawson
Posts: 129
Joined: Mon Nov 14, 2011 5:05 pm
Contact: Website

Re: on board (the rpi) software tools.

Thu Nov 24, 2011 2:07 pm

Tks @jamesh.
Playing with as, it seems to reject asm instructions written for the ARM assembler?
Do you know if that is the case? I'm thinking of privileged instructions,
stuff not present in a more general assembler?
I built binutils with --target=arm-thumb-elf and it seems only half way there?

Dave

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: on board (the rpi) software tools.

Thu Nov 24, 2011 2:21 pm

At a guess, you'll be wanting to configure with --target=arm-linux-elf, and your assembler will be named 'arm-linux-elf-as', not just 'as' (which will be the installed 'as' on your machine, which I guess is x86 of some flavour).

Some of the stuff on the ARM site is aimed at the realview assembler, which has a different syntax, but once you're past that, gnu's 'as' handles the instructions fine, I've found. If you give it the -mcpu=arm1176jzf-s flags, it *will* barf on instructions not handled by the processor, though (things like dmb/dsb)

Simon

dpawson
Posts: 129
Joined: Mon Nov 14, 2011 5:05 pm
Contact: Website

Re: on board (the rpi) software tools.

Thu Nov 24, 2011 2:51 pm

Thanks Simon.
Built that way... no problems.

arm-linux-elf-addr2line arm-linux-elf-ld arm-linux-elf-readelf
arm-linux-elf-ar arm-linux-elf-ld.bfd arm-linux-elf-size
arm-linux-elf-as arm-linux-elf-nm arm-linux-elf-strings
arm-linux-elf-c++filt arm-linux-elf-objcopy arm-linux-elf-strip
arm-linux-elf-elfedit arm-linux-elf-objdump
arm-linux-elf-gprof arm-linux-elf-ranlib

With a line
asr.W r0,r3

run ARM assembler
first.asm: Assembler messages:
first.asm:8: Error: unexpected character `w' in type specifier
first.asm:8: Error: bad instruction `asr.w r0,r3'

I.e. it is still disallowing the ARM.. as in the ARM assembler, instruction set?

I'm still seeing this as a GP cross compiler without explict ARM support?
Am I missing something else?

Dave

dpawson
Posts: 129
Joined: Mon Nov 14, 2011 5:05 pm
Contact: Website

Re: on board (the rpi) software tools.

Thu Nov 24, 2011 3:45 pm

@Simon. Getting there.
as cmd line params -m thumb targets 16bit instructions.
Now compiling without error.
I thought someone said this was Risc :-)
Makes some CISC processors look quite trivial!

Dave

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: on board (the rpi) software tools.

Thu Nov 24, 2011 4:16 pm

I probably wouldn't bother with thumb to start with, it complicates matters. the whole IT thing is a pita.

if you want to flag code as a particular instruction set:
.code 32
@arm mode here
.code 16
@thumb2 mode here

Simon.

User avatar
johnbeetem
Posts: 945
Joined: Mon Oct 17, 2011 11:18 pm
Location: The Mountains
Contact: Website

Re: on board (the rpi) software tools.

Thu Nov 24, 2011 7:49 pm

Quote from dpawson on November 24, 2011, 15:45
I thought someone said this was Risc :-)
Makes some CISC processors look quite trivial!


ARM was RISC at one time. Originally ARM was Acorn RISC Machine. Then it was Advanced RISC Machine. Now it's just ARM. If you think assembly language is complicated, take a look the machine language encodings. Back in the ARMv5 days they still had a list of instruction formats. They've long since given up on that. ARMv7 lists multiple instruction formats for individual instructions, but not for the instruction set as a whole. Writing a (dis)assembler for ARMv7 is pretty challenging. And it's a far cry from the PDP-11 where proper geeks could disassemble an octal dump in their heads.

I do understand why ARM did this. The instruction set evolved over the decades. For example, early ARM only had loads and stores for 32-bit longs and 8-bit unsigned bytes, so loads and stores for 16-bit shorts and 8-bit signed were later squeezed into gaps in the original instruction set. Thumb and Thumb-2 made things really interesting.

This is quite different from IBM's PowerPC where the instruction set was simulated to death before building anything, and the first PowerPC implementation was ECL wire-wrap (80 MHz IIRC). Yes, wire-wrap can be that fast as long as you use twisted pairs for clocks and other critical signals. So PowerPC was quite mature before it ever got to the chip level. Even so, PowerPC is not a trivial instruction set: the name stands for Performance Optimization With Enhanced RISC.

radu
Posts: 110
Joined: Mon Nov 21, 2011 8:19 pm

Re: on board (the rpi) software tools.

Thu Nov 24, 2011 11:23 pm

I think ARM assembly is pretty nasty. I am used to Z80 and X86 asm, which is pretty easy to follow. Almost like Basic. ARM, on the other hand, is painful to do by hand.

NimbyDagda
Posts: 6
Joined: Thu Sep 08, 2011 11:35 am

Re: on board (the rpi) software tools.

Thu Nov 24, 2011 11:34 pm

As far as I was aware ARMs are still RISC. RISC doesn't mean there are less instructions in the instruction set, just that all instructions operate in a single memory cycle, not in large complex cycles like you get for some of the CISC instruction sets.

PDP-8s had tiny instruction sets but were still a CISC as the instructions could take up to 10 memory cycles each.

kme
Posts: 448
Joined: Sun Sep 04, 2011 9:37 am

Re: on board (the rpi) software tools.

Thu Nov 24, 2011 11:46 pm

NimbyDagda, I think you mean clock cycles. Memory cycles is often not synced to the CPU clock.

hamster
Posts: 23
Joined: Fri Sep 23, 2011 10:20 pm

Re: on board (the rpi) software tools.

Thu Nov 24, 2011 11:47 pm

@NimbyDagda Humm,,, I could be swayed, but I don't that that that is valid statement.

Divide instructions always take more than one memory cycle (some are > 50 cycles), and some basic atomic operations will require multiple memory cycles (e.g. atomic test and set operations).

Caching also means that cores no longer have much visibility of memory cycles, and likewise the main memory doesn't see all instructions.

RISC and CISC are no longer really useful distinctions - it now is pretty much an indication of how many general purpose registers the architecture has. If nearly all registers can be used in all contexts it is pretty much termed RISC...

NimbyDagda
Posts: 6
Joined: Thu Sep 08, 2011 11:35 am

Re: on board (the rpi) software tools.

Fri Nov 25, 2011 12:00 am

@hamster Yes the changes in CISC design means some of the arguments about why RISC is better disappear, but that hasn't changed what RISC means. And last I checked there is no divide instruction in ARM assembly, it requires at least 10 or so instructions

@kme no its definitely memory cycles i.e. how many times in each instruction you have to go to memory as opposed to a register.

NoSuchNick
Posts: 42
Joined: Tue Sep 20, 2011 1:38 pm

Re: on board (the rpi) software tools.

Fri Nov 25, 2011 1:39 am

From what i remember back when i was coding for iPod linux, counting cycles on the ARM 7 CPU was a lot more complicated than a simple "1 instruction = 1 memory cycle", you had something along the lines of "this specific instruction = 2 clock cycles, 1 prefetch cycle + 2-4 memory cycles".
I just did a very short web search, to see if i could find my old instruction tables, but the best i could come up with was this:
http://netwinder.osuosl.org/pu.....FEvB_3.pdf for an ARM7500
and this
http://infocenter.arm.com/help.....gehcc.html for a ARM Cortex A9
In both documents you will see, that there are instructions that can take significantly longer than 1 cycle. Most notably the multiplication instructions, which can even take a variable number of cycles, depending on the complexity of the input numbers.

hamster
Posts: 23
Joined: Fri Sep 23, 2011 10:20 pm

Re: on board (the rpi) software tools.

Fri Nov 25, 2011 1:43 am

I'm having and idle day, so this is more chit-chat that anything of substance.

The ARM Cortex-M3 processor does have hardware divide (2-12 Cycles)...

Thumb/Thumb2 ISA seems to me to be something on the way to the instruction decode/translate units used on AMD CPUs to decompose CISC into basic operations for a RISC-like core.

Some instructions (like SRS & RFE) make two memory access, but I have to admit that you don't use them very often.

RISC / CISC processors is now more of a continuum - everybody agrees on the extremes, and can discuss at length on the middle ground.

User avatar
johnbeetem
Posts: 945
Joined: Mon Oct 17, 2011 11:18 pm
Location: The Mountains
Contact: Website

Re: on board (the rpi) software tools.

Fri Nov 25, 2011 3:59 am

AFAIK, there is no strict definition of RISC versus CISC, but I pretty much agree with http://en.wikipedia.org/wiki/R.....cs_of_RISC:

1. Uniform instruction format, using a single word with the opcode in the same bit positions in every instruction, demanding less decoding. [I would relax this to a few simple instruction formats, such as (a) load/store, (b) arithmetic/logic/shift, and (c) jump. PowerPC fits this, ARMv7 doesn't at all.]
2. Identical general purpose registers, allowing any register to be used in any context, simplifying compiler design (although normally there are separate floating point registers). [I would relax this to allow register 0 to have special meaning, e.g., always has value 0, and maybe allow PC to be a general-purpose register. However, the latter is problematic: ARM used to treat PC = R15 as a general-purpose register, but the newer instructions use R15 to indicate other instructions since PC often does not make sense as a general-purpose register. PowerPC does not allow PC to be a GPR, and considers R0 to have value 0 if used for addressing.]
3. Simple addressing modes, with complex addressing performed via sequences of arithmetic and/or load-store operations.
4. Few data types in hardware, some CISCs have byte string instructions [IBM 360 is particularly entertaining], or support complex numbers; this is so far unlikely to be found on a RISC.


IMO, one of the key hallmarks of RISC machines is ease of pipelining and multiple instruction issue. This is vastly simplified by having all instructions the same length so the decoder knows where to find upcoming instructions. This is harder with Thumb-2 where 16-bit and 32-bit instructions may be interleaved, though a decoded instruction buffer takes care of this. But it's a far cry from the DEC VAX which had instruction lengths from 1 to 60 bytes. Try pipelining that beast. That sure helped DEC's demise.

Another hallmark of RISC is being easy to compile into. Instructions that are hard for a compiler to use are good targets for omission. ARMv7 has a lot of these, but they are useful for DSP and graphics. Many ARM applications have been high-volume consumer devices like cell phones, so the cost of hand-assembling critical code is shared over a large number of copies.

"Come back tomorrow... we'll do fractions."

dpawson
Posts: 129
Joined: Mon Nov 14, 2011 5:05 pm
Contact: Website

Re: on board (the rpi) software tools.

Fri Nov 25, 2011 7:46 am

@tufty Thanks Simon, spotted that.
@johnbeetem Thanks for the history lesson. I can see the development cycle.
I worked on a wire wrapped TMS320 where we had four microseconds to complete a response, that was fun.

I'm now curious *which* instruction set I should be working with using arm-linux-elf-as.
If the one documented in the ARM documentation isn't supported ... is it documented in
GNU lib-utils documentation? I'll go chase.

Dave

dpawson
Posts: 129
Joined: Mon Nov 14, 2011 5:05 pm
Contact: Website

Re: on board (the rpi) software tools.

Fri Nov 25, 2011 7:53 am

Quote from hamster on November 25, 2011, 01:43

RISC / CISC processors is now more of a continuum - everybody agrees on the extremes, and can discuss at length on the middle ground.


Sorry, I didn't mean to start a flame war. <grin>Anyone want to discuss editors?</grin>

Lets settle for a simple fact IMHO, the instruction set isn't brief?

Perhaps settle for (/ (+ C R) 2) ISC)... or not!

Dave

NimbyDagda
Posts: 6
Joined: Thu Sep 08, 2011 11:35 am

Re: on board (the rpi) software tools.

Fri Nov 25, 2011 7:54 am

Quote from hamster on November 25, 2011, 01:43
I'm having and idle day, so this is more chit-chat that anything of substance.

The ARM Cortex-M3 processor does have hardware divide (2-12 Cycles)...


I haven't done anything with the Cortex stuff, so I didn't know that, thanks.

Quote from hamster on November 25, 2011, 01:43
RISC / CISC processors is now more of a continuum - everybody agrees on the extremes, and can discuss at length on the middle ground.


Yes that's something I can definitely agree with and I realise that most RISCs no longer stick strictly to the single memory cycle, but its definitely different to the 50 or 60 memory cycle instruction proliferation liberally sprinkled around the x86 instruction set.

I probably should have been more careful in what I said, this more started as my standard gut response to people conflating the idea of RISC with have less instructions, which was never what it was meant to mean.

Maybe I should have said its Set of Reduced Instructions, as opposed to a Set of Complex Instructions. Not a Reduced Set of Instructions as opposed to a Complex Set of Instructions, and left the weird bits of grey out.

I apologise for sounding snappy, it was late and I got all defensive.

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: on board (the rpi) software tools.

Fri Nov 25, 2011 8:41 am

TL;DR version - Just use ARM mode, but expect your assembler to barf on ARMv7 operands.

Short version - mostly, you can use either (or a mixture of both as long as you only use the same instruction set within one block of code and use bx/blx to jump between blocks that use a different instruction set).

Long version - On reset, the processor is in ARM mode, so reset handling has to be initially ARM (at least on the 1176, certain nominally "ARM" processors only support thumb, and thus start up in thumb mode). Exception handlers apart from reset execute in either Thumb or ARM mode, depending on the setting of SCTLR.TE[1]

I'd strongly recommend using only one instruction set, and the ARM set is both more extensive (Thumb only provides a subset of the "most commonly used" ARM instructions) and far easier to grok. It's also easier to decode / encode manually if that's your bag[2] :)

Next up, you need to deal with what variant of the instruction set you have. The 1176JZF-S is ARMv6[3], supporting the ARMv6T2 and ARMv6-K extensions. As such, you can use any of the ARM instructions marked ARMv5, ARMv6, ARMv6-K or ARMv6-T2 in the ARMv7AR-ARM, but not those marked ARMv7(anything). I'm not sure about the ARMv6[k]Z security extensions.

Oh, and it has "Jazelle version 1" as well. So you can poke Java bytecode at it if you are so inclined[4]. The very concept sends shivers up my spine

Simon

[1] B1.6.3 "Exception Entry" and B3.12.17, "c1, System Control Register (SCTLR)" in the ARMv7AR-ARM
[2] A5.1, "ARM instruction set encoding" in the ARMv7AR-ARM
[3] Appendix G, "ARMv6 Differences" in the ARMv7AR-ARM
[4] A.2.10.2, "Jazelle direct bytecode execution support" in the ARMv7AR-ARM

asb
Forum Moderator
Forum Moderator
Posts: 853
Joined: Fri Sep 16, 2011 7:16 pm
Contact: Website

Re: on board (the rpi) software tools.

Fri Nov 25, 2011 8:55 am

tufty: The ARM1176 doesn't support thumb2. Only the ARM1156-T2 does (from the ARM11 series).

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: on board (the rpi) software tools.

Fri Nov 25, 2011 9:03 am

Ah, my bad, that's what happens when you don't have the datasheet open in front of you. No ARMv6T2 instructions for us!

Even more reason to stick with ARM, though - as the book says:

ARMv6T2
Introduces Thumb-2 technology, giving a major development of the Thumb instruction set to provide a similar level of functionality to the ARM instruction set.

Simon

dpawson
Posts: 129
Joined: Mon Nov 14, 2011 5:05 pm
Contact: Website

Re: on board (the rpi) software tools.

Fri Nov 25, 2011 9:45 am

@tufty. thanks...I think :-)
Makes sense, ignore thumb since we're not exactly short on memory.

"Next up, you need to deal with what variant of the instruction set you have. The 1176JZF-S is ARMv6[3], supporting the ARMv6T2 and ARMv6-K extensions. As such, you can use any of the ARM instructions marked ARMv5, ARMv6, ARMv6-K or ARMv6-T2 in the ARMv7AR-ARM, but not those marked ARMv7(anything). I'm not sure about the ARMv6[k]Z security extensions."

<grin/>Sounds like a fair definition of complex to me!

so, instructions marked
ARMv5, ARMv6, ARMv6-K or ARMv6-T2 = good
ARMv7(anything) = bad.... (till tomorrow, for some such definition)

I'm now asking 'marked'... where? in the ARM asm documents?
Quick skim over the assembler_reference doesn't obiously mark each instruction...
But warning noted. Another one to tuck away for future reference!

Much appreciated Simon.

Dave

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: on board (the rpi) software tools.

Fri Nov 25, 2011 12:45 pm

Quote from dpawson on November 25, 2011, 09:45
I'm now asking 'marked'... where? in the ARM asm documents?

In the ARMv7AR-ARM, amongst other places.

Here's "BIC", which is allowed (encoding T1 and A1, T2 isn't as we don't have Thumb2)

And here's "DMB", which isn't

Simon

Return to “General discussion”