<ucadv07@gmail.com> skrev i meddelandet news:1171495132.249289.198340@v33g2000cwv.googlegroups.com...> > Had a discussion with a _hardware_ guy (as in transistors and OP-amps) > about "powerful" micros. > > He his a PIC guy and claimed that PIC have a very nice instruction set > and is a pleasure to work with in assembly. He also mentioned the he > would rather use a dsPIC instead of an ARM7 because ARM7 is very hard > to program and has a confusing assembly (we never talked application, > so I assume he meant this holds regardless of application). He also > said that another major advantage of dsPIC is that its a PIC, hence > the know-how and toolchain advantage... > > Completely shocked, I told him that my experience was the exact > opposite, and I really enjoy ARM assembler (well, maybe not enjoy...). > Anyway, after that, the discussion turned into a flamewar... > > > So what do you say? Maybe I have been wrong all the time? > > What do you guys think about the instruction set and architecture, > provided that you were forced to code in assembly and we ignored the > fact that these is more of an apples vs pink-flying-elephants > comparison... > > (you can also include your background and your other favorite micros > such as AVR and MSP4xx, but_ please_ don't flame. and you must REALLY > HAVE WORKED with all of them, no gusses please :) ) > > ((yes, I REALLY do want your answers. Because I suspect the answer > will differ very much dependent on your background, and experience and > your application, and I think that information would benefit this > little community)) > > -shocked >The Series 32000 instruction set is way superior to anything mentioned so far. The MC68000 instructon set is a murky wannabee in comparision. Try doing this in a single instruction on another architecture... pointer1->field1[ix1] = (unsigned int) pointer2->field2[ix2]; maps to: movzbd field1(pointer1(sb))[r0:d], field2(pointer2(sp))[r3:d] Elegance is Everything! -- Best Regards Ulf Samuelsson
PIC vs ARM assembler (no flamewar please)
Started by ●February 14, 2007
Reply by ●February 16, 20072007-02-16
Reply by ●February 16, 20072007-02-16
Ulf Samuelsson wrote:>... snip ...> > The Series 32000 instruction set is way superior to anything > mentioned so far. The MC68000 instructon set is a murky wannabee > in comparision. > > Try doing this in a single instruction on another architecture... > > pointer1->field1[ix1] = (unsigned int) pointer2->field2[ix2]; > > maps to: > > movzbd field1(pointer1(sb))[r0:d], field2(pointer2(sp))[r3:d] > > Elegance is Everything!Is it? I contend that the space required to hold all those fields in one instruction makes the generic instruction too big, and would prefer to execute two (or more) instructions. In a stack machine there will not even be a temporary needed. As a practicing dinosaur I believe in compact object code. For example, a stack machine could execute: lda field1; TOS := load address ldn ix; TOS := ix idx n; TOS := n*TOS + TOS lda field2 ldn ix idx n ld TOS := TOS^ sto; TOS^ := TOS and only lda need be larger than a byte. This also makes a good intermediate language if it is desired to port to a wide instruction machine, such as your 32000 above. The set also has great piping possibilities. -- <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt> <http://www.securityfocus.com/columnists/423> "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
Reply by ●February 16, 20072007-02-16
On Feb 16, 7:12 am, Paul Taylor <paul_ng_pls_...@tiscali.co.uk> wrote:> On Fri, 16 Feb 2007 11:50:17 +0000, Pete Fenelon wrote: > > It's a nice family. I did quite a lot of work on H8S, H8/Tiny (which I > > particularly like) and H8/300 a few years back and apart from > > Hitachi^H^H^H^H^H^H^H Renesas' tendency to move peripherals and > > IPRs around incompatibly they "just work" pretty well - good core > > with reasonable code density and nice interrupt handling, good > > peripherals, excellent timers, reasonable software tools. Very few big > > 'gotchas' when working with them. > > Looking at Renesas's recent advertising they seem to be pushing the R8C > processors more than their H8 range - so not sure what will happen to H8. > I think I read somewhere that essentially they will combine their two > ranges to just one.I was recently visited by the Renesas sales force in spite of being told I would be using an ARM part... they were very persistent and I decided the best way to chase them off was to let them try to sell me for a half hour or so. I listened to their spiel and started asking questions. A lot of them had to do with what is the difference between this part and that part, or this group and that group, or this family and that family... They started apologizing and admited that they product line was a bit chaotic. When I had looked at their parts for a design four years ago I had the hardest time even figuring out what they made! Every part was a separately presented design and you had to download the data sheet and read it all to figure out what it had. It was like the company never considered that there might be similarities between different parts. I never did figure out what they meant by "group" and "family"... I still don't know. Anyway, I haven't heard from the sales force for a couple of weeks. Once I pick an ARM part I may let them go head to head with it and see how they do.
Reply by ●February 16, 20072007-02-16
On Feb 16, 7:39 am, "Ulf Samuelsson" <u...@a-t-m-e-l.com> wrote:> <ucad...@gmail.com> skrev i meddelandetnews:1171495132.249289.198340@v33g2000cwv.googlegroups.com... > > > > > > > > > Had a discussion with a _hardware_ guy (as in transistors and OP-amps) > > about "powerful" micros. > > > He his a PIC guy and claimed that PIC have a very nice instruction set > > and is a pleasure to work with in assembly. He also mentioned the he > > would rather use a dsPIC instead of an ARM7 because ARM7 is very hard > > to program and has a confusing assembly (we never talked application, > > so I assume he meant this holds regardless of application). He also > > said that another major advantage of dsPIC is that its a PIC, hence > > the know-how and toolchain advantage... > > > Completely shocked, I told him that my experience was the exact > > opposite, and I really enjoy ARM assembler (well, maybe not enjoy...). > > Anyway, after that, the discussion turned into a flamewar... > > > So what do you say? Maybe I have been wrong all the time? > > > What do you guys think about the instruction set and architecture, > > provided that you were forced to code in assembly and we ignored the > > fact that these is more of an apples vs pink-flying-elephants > > comparison... > > > (you can also include your background and your other favorite micros > > such as AVR and MSP4xx, but_ please_ don't flame. and you must REALLY > > HAVE WORKED with all of them, no gusses please :) ) > > > ((yes, I REALLY do want your answers. Because I suspect the answer > > will differ very much dependent on your background, and experience and > > your application, and I think that information would benefit this > > little community)) > > > -shocked > > The Series 32000 instruction set is way superior to anything mentioned so > far. > The MC68000 instructon set is a murky wannabee in comparision. > > Try doing this in a single instruction on another architecture... > > pointer1->field1[ix1] = (unsigned int) pointer2->field2[ix2]; > > maps to: > > movzbd field1(pointer1(sb))[r0:d], field2(pointer2(sp))[r3:d] > > Elegance is Everything! > > -- > Best Regards > Ulf SamuelssonYeah, but how many days does it take to execute? ;^)
Reply by ●February 16, 20072007-02-16
On 2007-02-16, Pete Fenelon <pete@fenelon.com> wrote:> David Brown <david@westcontrol.removethisbit.com> wrote: >> >> The msp430 ISA is not perfect - some changes from the PDP-11 were >> improvements, some were clear tradeoffs for other reasons (smaller, >> faster or lower power design), and some changes were for the worse. But >> still, it is the nicest ISA available in a small, low power >> microcontroller at the moment. > > MSP430 also has the 'advantage' that what is included is the stuff that > a C compiler tends to generate ;P > > It's a very nice 'baby micro'. If you want something even more PDP-11ish > there's always the H8.What a coincidence: that's the other micro I'm currently using. Some of the instructions can get pretty long in an H8, but the assembly language generated by a compiler is a joy to behold. -- Grant Edwards grante Yow! .. does your DRESSING at ROOM have enough ASPARAGUS? visi.com
Reply by ●February 16, 20072007-02-16
On 2007-02-16, Ulf Samuelsson <ulf@a-t-m-e-l.com> wrote:> The Series 32000 instruction set is way superior to anything > mentioned so far. The MC68000 instructon set is a murky > wannabee in comparision.Definitely. When I was in grad school I took a 3-credit "microprocessor architecture" class which consisted almost entirely of comparing three 32-bit processor architecture: IA32, 68K, and 32K. Everybody in the class gave a presentation comparing one particular aspect of the three. The 32000 was definitely the winner (though I've heard unpleasant stories about bugs and support). The 68K was a definite second place, and the IA32 was seventh. -- Grant Edwards grante Yow! I'm pretending I'm at pulling in a TROUT! Am I visi.com doing it correctly??
Reply by ●February 16, 20072007-02-16
On Feb 16, 7:39 am, "Ulf Samuelsson" <u...@a-t-m-e-l.com> wrote:> > The Series 32000 instruction set is way superior to anything mentioned so > far. > The MC68000 instructon set is a murky wannabee in comparision. > > Try doing this in a single instruction on another architecture... > > pointer1->field1[ix1] = (unsigned int) pointer2->field2[ix2]; > > maps to: > > movzbd field1(pointer1(sb))[r0:d], field2(pointer2(sp))[r3:d] > > Elegance is Everything!Are we getting ready to fight the RISC/CISC wars again? I'll take a ringside seat! :)
Reply by ●February 16, 20072007-02-16
Ulf Samuelsson wrote:> <ucadv07@gmail.com> skrev i meddelandet > news:1171495132.249289.198340@v33g2000cwv.googlegroups.com... >> Had a discussion with a _hardware_ guy (as in transistors and OP-amps) >> about "powerful" micros. >> >> He his a PIC guy and claimed that PIC have a very nice instruction set >> and is a pleasure to work with in assembly. He also mentioned the he >> would rather use a dsPIC instead of an ARM7 because ARM7 is very hard >> to program and has a confusing assembly (we never talked application, >> so I assume he meant this holds regardless of application). He also >> said that another major advantage of dsPIC is that its a PIC, hence >> the know-how and toolchain advantage... >> >> Completely shocked, I told him that my experience was the exact >> opposite, and I really enjoy ARM assembler (well, maybe not enjoy...). >> Anyway, after that, the discussion turned into a flamewar... >> >> >> So what do you say? Maybe I have been wrong all the time? >> >> What do you guys think about the instruction set and architecture, >> provided that you were forced to code in assembly and we ignored the >> fact that these is more of an apples vs pink-flying-elephants >> comparison... >> >> (you can also include your background and your other favorite micros >> such as AVR and MSP4xx, but_ please_ don't flame. and you must REALLY >> HAVE WORKED with all of them, no gusses please :) ) >> >> ((yes, I REALLY do want your answers. Because I suspect the answer >> will differ very much dependent on your background, and experience and >> your application, and I think that information would benefit this >> little community)) >> >> -shocked >> > > The Series 32000 instruction set is way superior to anything mentioned so > far. > The MC68000 instructon set is a murky wannabee in comparision. > > Try doing this in a single instruction on another architecture... > > pointer1->field1[ix1] = (unsigned int) pointer2->field2[ix2]; > > maps to: > > movzbd field1(pointer1(sb))[r0:d], field2(pointer2(sp))[r3:d] > > > Elegance is Everything! >Elegance is not quite everything - and that instruction is not elegant. I don't have a problem with a processor taking three or four instructions to code an operation like that - on most cpus where you can have complex addressing modes, the instructions take many clock cycles and many instruction words, and could therefore be easily split into several instructions. I dislike architectures where you need several instructions to do the simplest of things, like loading a register with a constant, but I see no benefit in trying to do everything possible within a single instruction.
Reply by ●February 16, 20072007-02-16
On Feb 16, 10:40 am, Grant Edwards <gra...@visi.com> wrote:> The 32000 was definitely the winner (though I've heard > unpleasant stories about bugs and support). The 68K was a > definite second place, and the IA32 was seventh.Seventh out of three? Nice comparison...
Reply by ●February 16, 20072007-02-16
On Feb 16, 9:41 am, CBFalconer <cbfalco...@yahoo.com> wrote:> Ulf Samuelsson wrote: > > ... snip ... > > > The Series 32000 instruction set is way superior to anything > > mentioned so far. The MC68000 instructon set is a murky wannabee > > in comparision. > > > Try doing this in a single instruction on another architecture... > > > pointer1->field1[ix1] = (unsigned int) pointer2->field2[ix2]; > > > maps to: > > > movzbd field1(pointer1(sb))[r0:d], field2(pointer2(sp))[r3:d] > > > Elegance is Everything! > > Is it? I contend that the space required to hold all those fields > in one instruction makes the generic instruction too big, and would > prefer to execute two (or more) instructions. In a stack machine > there will not even be a temporary needed. As a practicing > dinosaur I believe in compact object code. For example, a stack > machine could execute: > > lda field1; TOS := load address > ldn ix; TOS := ix > idx n; TOS := n*TOS + TOS > lda field2 > ldn ix > idx n > ld TOS := TOS^ > sto; TOS^ := TOS > > and only lda need be larger than a byte. This also makes a good > intermediate language if it is desired to port to a wide > instruction machine, such as your 32000 above. The set also has > great piping possibilities.However your machine may be at executing the above code, it would only approach the speed of a single instruction which does the same thing. It has been a while since I looked at the instruction set of the larger CPUs, but I seem to recall that a lot of CPUs have wide variations in instruction length from 16 bits to 64 depending on the number of embedded addresses and such. The instruction above uses registers for much of the work, I believe. If I understand what it is doing, it is pointing to a structure, selecting a field that is an array and indexing into that for a transfer. I think your calculation is one offset short of this, but I can't be sure because I have not looked up the instruction. Regardless, one instruction does not make or break any CPU. In this case I think marketing broke this CPU so that the instruction set is moop.
