Compare ARM MCU Vendors

Since I'm intimately familiar with both, I'd be interested in discussing some of those decisions made in the 68k case if you are open to the idea in a public space.

The 9900 was very interesting, though I never had the chance to actually program one of them. If I recall correctly, it supported the visibility requirements of Pascal's local variables within nested functions. I'm not entirely sure I appreciate your comment about data flows because the Intel x86 did add some function prologue/epilogue instructions later on to also support that feature... but you are probably referring to some other aspect I know zero about.

Good books on this subject, too. I remember talking with one of the founders of MIPS (Hennessey) about his analysis of the

PIC and 6502 being examples?

As in the Intel REP MOV or the DEC PDP-11's MOV (R5)+, (R6)+ as two very different examples?

I think I remember some comments you made about this, earlier.

Thanks, Walter. I enjoyed reading this.

Jon

That is precisely while I put the inverted commas around "wrong". ISA's like Thumb2 or ColdFire are more efficient than the x86 or ARM instruction sets using modern design and fabrication techniques - I fully agree that the situation was different 30 years ago (well, 21 years ago for ARM, IIRC). There is also the minor matter of trial-and-error - we know better know based on experience from past designs.

However, it is still valid to compare the x86 and the m68k architectures because they were from a similar time. The x86 was considered poor and old-fashioned when it was first made, and not suitable for powerful computing. The m68k was considered an elegant and modern design, with forward-looking design choices (such as support for 32-bit in the ISA, even though it only had a 16-bit ALU in the implementation). It was not without reason that the IBM engineers wanted the m68k for their new "PC".

In my mind I'd made the cut between specialized-register machines (i8080 etc., Z80, TI32000 DSPs, DEC 8, GE-635) and general-register machines (m68k, mc6800 -- sort of, m88000 DSPs, DEC 11, IBM360). Specialized were easier to code for because after you'd figured out which registers your data had to be in the low-level code was pretty much determined; general registers needed a conscious resource-allocation step. In code performance, the only head-to-head comparison I've done was to rewrite identical functions for Z180 and MC68HC11. The functions always took less code memory and less execution time on the HC11. Partly because there was less data-shuffling (and partly because HC11 conditional-branch operations were handier.)

Mel.

The 68k guys certainly did that - and they created the 68k assembly language, which has been the most efficient native CPU assembly language I have seen since.

But the power architecture designers did a great job, too - apart from the barely if at all usable native assembly mnemonics.

I can hardly think of something I miss from the 68k on the PPC; and you will be surprised how little code size difference there is if you write with the PPC in mind (on VPA, which is what I call the language I built over the 68k assembly to produce PPC code).

Some examples:

Power takes advantage of its 32 bit opcode size and lets us leave the condition codes unaffected if needed; not so on the

What I do miss from the 68k is the movem instruction with a bit per register which will be moved; VPA does this on power by simply doing a single move per register. I suppose this is one of the major code space eaters I have in my code. They do have a native move multiple opcode, but only for sequential registers and I do not use it much.

But the rlwinm, rlwnm and rlwimi PPC instructions are a major help. While the 68020 did have bitfield instructions, they did not make it to the cpu32 and were probably too bulky to implement; these 3 opcodes with a little help from others can really do a lot, I would not give them up, not without a fight :-) .

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

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

That and insisting on numbering bits the opposite way to everyone else.

-a

ROFL, I don't know whether to strongly agree or to strongly disagree with you :D .

Strictly, since it is big-endian, the numbering they use is correct. Heck, even the RFCs do it "officially" so. The technical implication is that bit, byte, word, long word, dual word etc. addressing is done only using shifting and AND, no complements need to be calculated (my vpa has to do that on rare occasions for 68k emulation, like:

OTOH after many years of using both notations, even though I am now used to have them simultaneously, it is still a pain. Routinely manageable, but a pain. E.g. many times I do not go the extra mile to halve the code size of the example above, just use it as it is there to avoid the headache.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

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

HC11 and HC08 both have reasonably good code density. THere are many arguments for and against conditional branch vs conditional skip. In benchmarks conditional branch generally wins but on some very time critical code conditional skip wins.

Motorola's conditional branch set is complete but has limited range resulting in "5" byte two instruction long branches in some code.

I am surprised that the 6809 has yet to show up in this discussion

Regards,

w..

-- Walter Banks Byte Craft Limited

:D

Indeed. But even I - having grown up on it - have long since put it out of use :-).

But since you asked for the 6809, here are it is - 3 instances of it emulated in DPS windows, the tiniest being as large as the graphics board I had built back then.. only here in colours, that first graphics board of mine had 2 bits/pixel I used to view on a mono monitor...

Oh no, I can't believe all these years have passed. Walter, you really should not have asked that :D :D .

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

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

I consider the 68000 to be a nightmare compared to a real orthogonal machine like the Series 32000...

This did not fix the location of the fields though, so you would get a messy instruction decoder. The immediates were 7,14 or 30 bits wide with the size encoded in either the top bit or the two top bits.

I think variable size, fixed location of fields seems to be most efficient. The National CompactRISC was one of the first implementations of this idea.

Internally, the decoder would decode directly the 16/32/48 bit instruction for a simple pipeline. For multiple clock functions like interrupts & exceptions there were 7-8 state machines that could override the instruction decoder.

Since the datapath was controlled by ~90 signals, this turned out to be a significant part of the chip.

Turned out that this could be simplifed further. The reason for the state machines were that you need to do operations which are not supported by the instruction set.

When you enter an interrupt, you need to clear the interrupt flag. This is really an (unsupported) instruction

AND $IRQMASK, PSR I.E: AND 0xFF7F, PSR

The problem we found, was that you need to do operations on registers which are not accessible,and you need a few more instructions.

The problem was solved by extending each register address from 4 to 6 bits, allowing all registers (including PSR) in the CPU to be directly addressable by all instructions operating on registers. The opcode was extended by two bits allowing more instructions to be directly handled.

The normal instructions was extended from 16 bits to 22 bits but user code, would only use the normal 16 bits. If a multiclock function was needed, then the instruction decoder was fed from a 22 bit wide ROM which ran for a few clock cycles.

The issue "big endian" vs "small endian" was resolved years ago, when it was finally realized that "the only good endian is a dead endian"

Some of the instructions are barely understandable in assembly - but it's designed to be used with a compiler, not assembly.

And the EIEIO instruction is wonderful.

Yes, the PPC's bit numbering does not make it easy to understand. I've used a couple of the MPC5xxx devices, and the reference manuals are cryptic enough without having to deal with bit 31 being the LSB. It gets even more fun when some registers are 64 bit, and the LSB becomes bit 63. And if you have a part with more than 32 address lines, the LSB stays A31 for consistency - and the lines above A0 are numbered A-1, A-2, etc.

Indeed, but in VPA the same instructions are as easy to use and understand as in 68k assembly, so it is a matter of the mnemonics they have chosen, not the instruction set. For example:

these look pretty familiar and "normal".

Below is the list of the same with the native PPC mnemonics VPA generates, now these do not look that straight forward :-).

Op Sat, 25 Sep 2010 00:28:10 +0200 schreef Ulf Samuelsson :

I prefer the term "cul-de-sacian"

But then what do you call two of them: culs-de-sacian or cul-de-sacians? 8-)

"ded enjuns" is not only appropriate, but funny too.

George

Op Mon, 27 Sep 2010 19:09:12 +0200 schreef George Neuner :

I hope not a lot of people will find genocide appropriate and/or funny.

Grow a sense of humor.

And watch where you sling the "G" word ... your ancestors have as much to answer for as do anyone else's.

George

Sorry. I apologize for the last message ... I did not mean to imply anything in particular with respect to your family, which I have no knowledge of.

Rather I badly phrased my thought that, if you go back far enough, everyone has regrettable violence in their personal family history. It is a sad truth that people just don't have to go back as far.

George

Op Tue, 28 Sep 2010 21:33:59 +0200 schreef George Neuner :

Read my previous posts and judge again. Hint: I seem to be funniest in April.

Anyway, I did not wish to spoil your fun, I was merely trying to emphasize the fact that we are making fun with dead Indians, and not making fun of their deaths.

The (alleged) actions of anyone's ancestors should not have any influence on their opinion of genocide.