Sample ARM assember code?

Get the newlib sources (Google for it).

Prepare to be disappointed: Most of the libraries are written in C.

If you absolutely insist on assembly code, you can translate the sources with assembly listings, adding '-Wa,ahlms=file.lst' to the GCC command line. Substitute the source name for 'file' above.

I'm not used to a register machine with only load and store for memory access and just wanted to crib some techniques

Really I though you were an expert at low level programming

Are you saying that the ARM does not have any index registers? I find that hard to believe

That's part of the 'culture shock' of going to pure RISC. Only one memory access per instruction. No memory to memory accesses, searches, etc.

oh no any register can be used as an index

what are you actually finding to be difficult?

PDFTT.

I think he means that the ARM has no register-storage (or storage-storage) instructions where one or more of the operands can be in storage. For example X86 or TI MPS430 series (a RISC processor only in the drug addled brains of the marketing folk)

On 07/06/16 05:39, Jeff Jonas so wittily quipped:

old-school assembly programmers were used to that, particularly on things like 6502 and really old minicomputers that only had accumulators and index registers.

Right.

Memory-to-memory operations, like moves, are always really firmware doing loads and stores in a loop.

RISC machines simply expose the more microcode-like instructions implemented by hardware.

Consider the complexity of a firmware move loop on a virtual memory machine, where each operand and the instruction itself may cross page boundaries, leading to three potential page faults in a single high-level instruction!

This may not be what your looking for but on the offchance see the site brucesmith.info ( books for the serious programmer ) where you can find references to Raspberry Pi ASSEMBLY LANGUAGE (3rd edition) and other resources.

Get the newlib sources and compile them. It *is* a standard C library.

Most of the code is in C, so for assembly listings, you need to add -Wa,-ahlms=thefile.lst to the GCC command line. Substitute the source name for 'thefile'.

You can start at .

As a footnote:- If you are rearly keen to jump in the deepend of a new experience its better to take along a 'life (sanity) preserver' to rescue yourself from drowning in a new enviroment.

The 6502 was not so bad. It had fewer registers than the Motorola 6800 to reduce die size and complexity, thus the lower cost but it still had index registers that could be used almost as well as general purpose registers.

It even had SOME memory-to-memory operations. Citing

Read-modify-write instructions (like INC) read the original data, write it back, and then write the modified data.

-- jeffj

Google found that 6502 folks shared libraries for such needs:

I think you mean "microcode", not "firmware".

I'd hate to be a nit-picker, but to me "firmware" refers to ROM-code. Arduino-like microcontroller systems tend to be called "embedded systems" because they run totally from ROM/read-mostly-flash. For larger systems, the ROM tends to be ignored once the full system is booted. The IBM PC originally ran both load-on-demand user programs with "hooks" to the BIOS: motherboard and peripherals. But that was all single-threaded.

"microcode" is loaded upon power-on, extending the instruction set.

I believe the Z80's memory-move was totally hard-wired hardware. No microcode. Or perhaps a microcoded-state machine that was hard-coded into the silicon.

The IBM 360 had a more pathological situation: an execute instruction, on a page boundary executing a move-character instruction, on a page boundary where the source spans a page boundary and the destination spans a page boundary. That requires 8 pages loaded simultaneously to resume execution.

-- jeffj

I was told a different reason the 6502 has fewer registers and such than the 6800--IIRC, either in class or in conversation while I was in college. I was told that the 6502 originally was going to have wider (16-bit, IIUC) index registers and more instructions, but Motorola threatened to sue because of similarity to either the 6800 or 6809, and the 6502 feature set was reduced to avoid being sued. IIUC, some of the 6502 designers had worked at Motorola, and Motorola claimed they were taking Motorola IP in the original design of the 6502.

My experience was that after programming the 6809 with its 16-bit index registers, the 6502 was underwhelming. One time, I coded up a homework assignment in assembler for 6502, 6800, and 6809. The 6502 took the largest number of instructions. The 6800 took two-thirds as many as the 6502. The 6809 took half as many as the 6502.

HTH

I never heard that. And as I understand it, the one suit filed by Motorola was against the 6500, for being pin-compatible with the 6800. MOS Technology changed the pinout and the lawsuit was dropped and the 6502 was born.

Much depends on how data is laid out.

In my experience, it is seldom necessary to index beyond 255 bytes if the data is structured appropriately for the 6502. It is helpful to think of page zero as 128 16-bit registers. ;-)

Then there's the fact that the 6502 executes instructions in very few cycles compared to its contemporaries...

indeed a 6502 running at only 1mhz (as used by Commodore) could certainly equal if not outperform a z80 runinig @4 mhz The BBC @2 mhz was a blisteringly fast machine of the day.

Not in my experience, but there ya go. Depends on what it was running

Hmmm, 6502 was out a long time before the 6809. There was problem with the MOS 6500 being pin compatible to the 6800 so the 6502 was produced (which isn't pin compatible).

A real programmer knows the 6502 had 128 16bit index registers. :-)