PIC vs ARM assembler (no flamewar please)

Its about index registers and ease of

branching and the creating Primatives

that allow you to code , w/o an assembler .

When i need to do low level , i dont

need an ISa that forces me to push/pop

every time i want to repeat the thread

on new data as the mighty Pentium

must do , for it has only 2 index registers !!

The mo index registers , the less pushing

and poping !

Also there is a way to nix CALL/RETURN

that i invented .

Its simply indirect branch thru a register

that you dedicate . It allows you to do

sub routines , but no need to RETURN .

Instead , you go directly to the next

subroutine . FAST .

ALL ARM cpu can do

[ Load PC (Rx) ]

The mighty Pentium struggles , with

JMP ( AX ) .

ARM is the fastest ISA , and its so

easy to use .

Ill be giving a free O.S. for ARM .

It is layered . 8 KB , 200KB , 5 MB .

It uses NO text , its a true GUI .

---------------------------------------------

Fit it to C ?

The objective is to create a way to assemble

code without text ,

but think you are at high level GUI .

You wont understand this , since you are C programmer .

Thus the nuemonics dont matter ,

but the regsiter set DOES matter .

The SUCK pentium has SI , DI .

The $2 ARM7 has 14 ,

32bit Index Registers , to save you from

pushing/poping half your code away !!

I can systems program , faster than

the worlds fastest C programmer ,

using a new 100% structured , modular

method , that uses NO text , but GUI .

It is NO secret ,its just tossing , til it

works .

It uses a layer above the OpCodes that

is so general , that each of these primatives

totally conceils the ISA ! It decides which

and how many Reg's to use for all low level

applications . It has a user stack that goes

away at run time . And worse ! Run time

disables INT's !

The kernel threads with a perfect , unargueable path , thru all threads , at all levels .

ARM ........2 billion and growing ..

I dislike architectures where you need several

___________________________________

Well you will love TI430 for loading constants You can put the constants in ur code as instructions , instead of storing them in Data Space .

But seriously , its not constants , its about loading addresses .

---------------------- Loading pointers indirectly . and decreasing PUSH/POP .

Long ago TI had its registers in RAM ! ( 64 pin "99000" ) , context switch was fast ! and you could have hundreds !

But ARM is as good as it gets . It will devastate MicroChip , Zilog , Atmel Intel , AMD , Micron , .......

Hey ! ATMEL do ARM ...

But it can't compete with Japan/Korea wafer fab ...

Stay tuned for my free O.S. , fits in 8KB and it grows to 200K then 5 MB .

Zilog have this in their current uC. It's also something Atmel could/should have done with their AVR, and it is a common shortcoming of RISC devices in Microcontrollers. RISC cores are historically pitched by die area, and memory is 'NIH', and so we see pointer/stack thrashing. -jg

you actually learn the >>next. After learning half a dozen,

---------

_______________________________________

Its terrible to hunt for jobs like that !

I simply choose the one that is the

best for 'use" , not for making money .

Do you know what use is ?

It means , i want lots of RAM and an

instruction set that is fast to create s/w .

Because stuff is on batteries , it must

not make heat , ARM does same job

in half the watts , as PIC , 8051 , and

all of the Philips super-8051's and

Zilogs and Rabbits .....

It is so good , its destroying market

share of all others . It has sold

2 billion mcu's . No one is close .

So if you are confused , about which

mcu to program , you will pay a much

higher price for that mcu , and thus there

will be no jobs ,programming it in the

future .

Thats competition , it kills the 2nd place

finisher . In 3 mo years , only ARM

will exist , and it will come with a 32KB

opsys and cost $2 . Anything you hook

to it will run , because all the "protocols"

will be simpler and "open" .

Its progress .....

until you actually learn the >>next. After learning half a dozen,

I actually enjoy learning from challenge. I wrote, "I like them all and enjoy working with them." I had two points -- one is that the instruction set simply isn't on my radar when selecting a part and two is that "I enjoy getting into the 'mindset' of most any instruction set design."

I don't find any of that terrible, at all.

But to each their own, sir.

Best for use is a complex set of tradeoffs in my world. It's not a simple decision. Best for money I didn't even discuss. That is a strawman you bring up.

If I couldn't, I'd find some other work.

Great. If that works for you, more power to you.

Ah. Well, I've no business telling you your business, but you have none telling me mine, either. I also care about battery use. But in my case, that often argues _against_ excessive RAM. Only you know for sure what you mean by "fast to create s/w," since you didn't describe that in detail here. So I'll just leave that comment alone.

ARM has low power as a goal, of course, but ARM is NOT the best processor for all uses. Not even close, yet.

It almost always comes in huge packaging, often has an external memory interface (which I rarely ever need), sometimes requires a separate supply for core and for I/O, etc. Not to mention that it is NOT the lower power selection. MSP430 comes to mind.

Your position seems to be the very extreme one of believing you know everything about everyone else's problems and that therefore you know a panacea to all problems. The problem with that is that everything is a matter of tradeoffs. And the ARM is not the best combination of tradeoffs for all problems. And you don't know everything.

It's as simple as that.

That said, I don't use Rabbits or Zilogs, either. They just haven't been what I needed.

I like ARMs and I am very glad they exist in so much variety. They still aren't a panacea.

I'm not confused. But you seem to be, imagining that you know everything about everything. I try to know my problems well and I just have to disagree with your premise that the ARM would always be a viable option in every case, let alone the better choice.

Glad to hear it.

Of course, I don't believe you.

Jon

I would be interested in hearing more if you would like to elaborate on what you think those are.

Common, yes, but not for every instruction. The most common instruction is always execute, no shift, and one of the source regs is the same as the destination.

True, but 4/3 of 16 bits = 2/3 of 32 bits, itself an indication of how much instruction space is wasted in the ARM design.

Yes, but a pure 2-operand instruction set requires additional moves to avoid overwriting the destination register. Thumb has various 3-opnd instructions to reduce this.

Correct, the information content of ARM instructions is around 19-20 bits per instruction. However you can't get there using a fixed length encoding, so neither ARM nor Thumb are optimal. Thumb-2 uses mixed 16/32-bit encodings to get the best of both worlds.

You can do better still with significantly more complex encodings, and get down to about 50% of ARM codesize. However it's unlikely it is worth the hardware complexity. RISC focuses more on easy decoding...

Wilco

... snip ...

What this really does is require a dedicated temporary register, which is no longer available to the programmer. The temporary may be virtual.

--
 
 
 
 "A man who is right every time is not likely to do very much."
                           -- Francis Crick, co-discover of DNA
 "There is nothing more amazing than stupidity in action."
                                             -- Thomas Matthews

I suspect that memory-to-memory operations are more common and the load/store RISC requires a temporary register for this.

Thumb? I thought all the three-operand instructions were removed from Thumb.

True to a degree, but ease of decoding doesn't require three-operand instructions, conditional execution of every instruction, etc.

The NS32532 was about two times the speed of the x86/68k competition of its day 68030. The NS32764 (later Swordfish) was one of the first Superscalar RISC processors and would execute code faster than any of the other RISC processors in that time period. It would decode the instruction into risc instructions before execution. The final version of course skipped the 32000 instruction set altogether.

You code does not do all the things the instruction above does. Surprisingly enough, I think that complete instruction can fit into 8-9 bytes depending on the length of the displacement.

This is due to the encoded immediates in the Series32000 architecture. It supports 7,14 and 30 bit immediates like this (IIRC).

0xxx_xxxx 10xx_xxxx_xxxx_xxxx 11xx_xxxx_xxxx_xxxx_xxxx_xxxx_xxxx_xxxx

--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

I presume you are referring to the AVR here, rather than my PPC comments.

There are, I think, four main areas where the AVR is poor regarding C.

First, it is 8-bit, while C requires 16 bits in many areas. There are a couple of 16-bit instructions, such as movw instructions in later cores, but a few more such instructions could have greatly reduced the overhead of using 16-bit data on an 8-bit cpu.

Second, the split memory space makes it virtually impossible to write a compiler that is standards compliant, efficient, and easy to use regarding access to constant data in flash. Various solutions include introducing new non-standard "flash" keywords, abusing existing "const" keywords, and using user-unfriendly macros. The banking system for the

128 kB and up AVRs makes it even worse.

Third, there are only three pointer registers, only two of which support displacements. This is just too limited for C, and leads to thrashing for code that uses pointers, structs, or arrays.

Fourth, the stack pointer is accessible only as an external register using 8-bit access. This leads to a lot of overhead for stack frame access, and means that one of the pointer registers is needed as a frame pointer. Small functions can keep their parameters and variables in registers, but more complex code requires stack data.

It is issue 2 above that is the real killer - the others cause big, slow and inefficient code, while the split memory space stops code being re-usable across compilers and targets.

None of this stops the AVR from being a very nice family of microcontrollers - it is just that they are not nearly as "C friendly" as their marketing people would like to claim.

mvh.,

David

That's beginning to sound like the ColdFire (which Freescale refers to as a "variable instruction length RISC processor").

Not really. ColdFire is a 68K variant removing some of the less frequently used instructions and complex addressing modes. Although this allows for simpler and faster implementations, the instruction set remains as CISCy as the 68K. It's all marketing...

There are few RISCs with variable length instructions.

Wilco

I'm not sure what you mean. z = x + y needs an extra move on any

2 operand architecture (assuming x and y remain live).

Thumb has 3 operand add and loads, for example:

ADDS r0,r1,#0..7 ADDS r0,r1,r2 SUBS r0,r1,#0..7 SUBS r0,r1,r2 LDR r0,[r1,#0..124] LDR r0,[r1,r2] STR r0,[r1,#0..124] STR r0,[r1,r2]

Indeed, but it doesn't make decoding harder either. Other RISCs simply have unused bits, while on ARM they have a use that significantly improves codesize and performance. Despite this, fixed 32-bit instructions are not optimal.

Wilco

meddelandetnews: snipped-for-privacy@t69g2000cwt.googlegroups.com...

Nice diversion, but you didn't answer the question. How long did it take to execute the instruction you describe above?

But your comments bring up another question. If it was so good, what happened???

Obviously there is more to a processor than just how fast it runs code. Just ask Intel, they will tell you so.

Using RAM for registers in the way that the TMS9900 did is a concept that had its time and the world has moved on. It made sense when register and memory has nearly the same speed. Now that memory is the speed bottleneck for CPUs, it would be horribly slow to implement. The TMS9900 used a pointer register (that's right, registers did not go away) to point to the first register in memory. An ADD would then take three memory accesses to complete rather than one clock cycle. Even if you put the memory on chip, you either have to limit the location of the registers to a special bank of fast, multiport memory (register bank) or you have to accept multiple memory cycles for a single instruction, even when working in registers.

I think I still have a TMS9900 board around somewhere along with a TMS9995 board I built myself in wirewrap.