Prev: Tiny Bootloader
Next: Link&Locate 86?
From: Ulf Samuelsson on 3 Sep 2006 12:30 > You can reality check this for 2005/2006 by comparing Atmel/Microchips > annual reports : total shipped (all) AVRs [all cores, mask & ram & smart > cards] passed 500M a little while ago, whilst (all) PIC's are into their > 3rd billion IIRC. But then again, PICs have been shipping since the late 1970's -- 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
From: Ulf Samuelsson on 3 Sep 2006 12:38 > A good, very current example, is the ZNEO from Zilog. > > Zilog pitch this as a 16 bit uC, as the base opcode is 16 bits, with some > larger opcodes. But it has 16 x 32 bit registers, and can do 64 bit > operand maths. Compare that with the CortexM3 (another new core), it has > 16 x 32 bit registers, and the base opcode is 16 bits, with some 32 bit > ones. Great, this discussion pops up again :-( So the AVR with its 16 bit instruction is a 16 bit uP? And the PIC12 is a 12 bit controller? The only interesting thing is the width of the datapath in the instruction set. I.E: what is the maximum width the majority of the arithmetic instructions use. This probably puts the ZNEO in the 32 bit class. -- 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
From: Ulf Samuelsson on 3 Sep 2006 12:41 > Jim, the first thing I like to look at is the size of the ALU. Then, I try > to look at > the size of the internal register datapath. Easiest way for me to do this > is look at > instruction execution times. If it takes only one cycle to do a 16-bit ADD > and they call > it a 16-bit, I call it a 16-bit. > > But if 16-bit moves take twice as long as 8-bit and 16-bit arithmetic > takes about twice > as long as 8-bit, it's an 8-bit to me. Just hardcoding an instruction to > do "big math" > isn't enough for me. > The MC68000 is a 16 bit implementation of a 32 bit architecture and it takes 4 clocks to do a 16 bit add. Is this a 4 bit architecture? -- 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
From: Paul Carpenter on 3 Sep 2006 14:03 On Sunday, in article <tEDKg.116$Ue.85(a)nntpserver.swip.net> ulf(a)a-t-m-e-l.com "Ulf Samuelsson" wrote: >> A good, very current example, is the ZNEO from Zilog. >> >> Zilog pitch this as a 16 bit uC, as the base opcode is 16 bits, with some >> larger opcodes. But it has 16 x 32 bit registers, and can do 64 bit >> operand maths. Compare that with the CortexM3 (another new core), it has >> 16 x 32 bit registers, and the base opcode is 16 bits, with some 32 bit >> ones. > >Great, this discussion pops up again :-( >So the AVR with its 16 bit instruction is a 16 bit uP? >And the PIC12 is a 12 bit controller? > >The only interesting thing is the width of the datapath in the instruction >set. >I.E: what is the maximum width the majority of the arithmetic instructions >use. >This probably puts the ZNEO in the 32 bit class. Along with H8/H8S/H8SX/H8 Tiny. -- Paul Carpenter | paul(a)pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.gnuh8.org.uk/> GNU H8 & mailing list info <http://www.badweb.org.uk/> For those web sites you hate
From: David Brown on 3 Sep 2006 16:06
Jim Granville wrote: > Bill Giovino wrote: >> "Jim Granville" wrote... >> >>> Chris Hills wrote: >>> >>>> I would say that the market will split into 8 bit and 32 bit. Apart >>>> from a few specialised parts like the MSP430 the 16 bit market will die >>>> out. >>>> >>>> Book mark this post and get me to eat my hat in about 5 years time :-) >>> >>> Do we have to wait ~5 years ? >>> >>> Spin and marketing will conspire against such predictions. >>> >>> A good, very current example, is the ZNEO from Zilog. >>> >>> Zilog pitch this as a 16 bit uC, as the base opcode is 16 bits, with >>> some larger opcodes. But it has 16 x 32 bit registers, and can do 64 bit >>> operand maths. Compare that with the CortexM3 (another new core), it has >>> 16 x 32 bit registers, and the base opcode is 16 bits, with some 32 bit >>> ones. >>> It can multiply to 64 bit result, but seems to lack a 64/32:32 >>> - this is pitched as 32 bit controller. >>> >>> Who is 'right' ? >>> >>> This shows the flaw in trying to firstly pigenhole uC into boxes, and >>> then moving pick winner(s) and looser(s). >>> >>> Freescale look set to somewhat abandon these 8/16/32 bit pigenholes, >>> so maybe in 5 years time, we'll look back on attempts to quantify >>> complex devices with a single number, as quaint ? :) >>> >>> -jg >> >> >> Jim, the first thing I like to look at is the size of the ALU. Then, I >> try to look at >> the size of the internal register datapath. Easiest way for me to do >> this is look at >> instruction execution times. If it takes only one cycle to do a 16-bit >> ADD and they call >> it a 16-bit, I call it a 16-bit. > > If it takes one cycle to do a 32 bit add, that would be 32 bit ? > >> >> But if 16-bit moves take twice as long as 8-bit and 16-bit arithmetic >> takes about twice >> as long as 8-bit, it's an 8-bit to me. Just hardcoding an instruction >> to do "big math" >> isn't enough for me. >> >> This is a quick view - pipelines and other considerations can make >> things more >> complicated. >> >> Dataquest used to go by the size of the external databus (bad way to >> do it). > > Yes, and that's quite valid too. Of all the different ways people determine the bit-width of processors, this is the second least valid (after the internal flash width, giving us "12-bit" and "14-bit" PICs). Consider the 68k family mentioned by Ulf - the 68020 has a 32-bit external bus, the 68000 has a 16-bit bus, and the 68008 has an 8-bit external bus, yet all are virtually identical internally from the programmers' viewpoint. > > Problem is, you now have a different yardstick to everyone else :) > > The key point is, it is futile to pigenhole these things to any degree > of precision, because everyone uses different yardsticks. > There are two commonly used yardsticks for bit-width - the width of the processor's general purpose register(s), and the width of its ALU (with a total disregard for clock cycle counts - it's the programmer's viewpoint that is vital). In the great majority of cases, these are the same, and almost all cpu architectures can be easily and uniquely classified in this way. There are some major exceptions, such as the Z80, which would have to be classified as an 8/16-bit processor. > A break down by pin count, or Flash size, would be more informative, but > those stats are not crunched. > Certainly - bit-width of the processor is far from a complete description of the device, or its power or speed. There are plenty of fast 8-bit devices that are faster than slower 16-bit or 32-bit devices, and an embedded developer is interested in many more things than some raw speed measurement. > -jg > > |