So: Anti software bloat
in [Design]
|
From: Paul Keinanen on 20 May 2010 14:51 On Thu, 20 May 2010 11:25:00 -0700, "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote: >"Tim Williams" <tmoranwms(a)charter.net> wrote in message >news:ht3td0$buu$1(a)news.eternal-september.org... >> CISC means "we give you these powerful-assed instructions that'll solve >> field equations, but they take forever to compute and we only let you use >> some operands some of the time, see reference for what". > >Many would argue that, when it comes to CISC, "only letting you use some >operands some of the time" is limited to slightly brain-damaged >implementations such as x86... ;-) Many claim that VAX-11 was the ultimate CISC architecture, however, each instruction could use all the available addressing modes. In character string and packed decimal (BCD) instructions, up to six operands (SrcAddr1:Len1, SrcAddr2:Len2, DstAddr:DstLen) was used and each operand could occupy 6 bytes (indexing, addressing mode + offset/constant), so with the opcode, a single instruction could be 37 bytes long :-).
From: MooseFET on 20 May 2010 21:19 On May 20, 11:01 am, "Tim Williams" <tmoran...(a)charter.net> wrote: > "Bitrex" <bit...(a)de.lete.earthlink.net> wrote in message > > news:B_WdnZjD1YjqQmnWnZ2dnUVZ_omdnZ2d(a)earthlink.com... > > > Atmel sez: > > > "Many people believe RISC is an acronym for "Reduced Instruction Set > > Computer", and that a RISC must have a limited number of instructions. > > ... > > RISC basically means, "we don't let you do anything in one, you always have > to load-modify-store manually, but at least it goes screaming fast and the > operands are simple to remember". RISC really does mean "reduced". The rarely used or way complex instructions are left out in favor of using those same transistors to get more of the useful stuff done in a second. RISC machines often have a fixed instruction length and a large number of registers but this need not be the case. > CISC means "we give you these powerful-assed instructions that'll solve > field equations, but they take forever to compute and we only let you use > some operands some of the time, see reference for what". Back when CISC were not yet call "Complex Instruction Set Computers" because there was no movement to the RISC side, Intel did a fair amount of talking about "software on silicon" where common tasks were coded right into the CPU. About the highest extreme on this was the 432 machine that they made some of but later withdrew and burned all files about. It was reported that they also shot all the people involved, had them buried 12 feet down and then shot the ones who did the shooting, just to make sure that no memory of that dreadful machine remained. > The 8086 did 16 bit multiply and divide, but it took up to 140 cycles to do > it (tons of microcode). Tons of addressing modes, but these were only > available on a few instructions. SRC and DST operands were exclusive to > some extent, so for example, you can't MOV [mem2], [mem1], you need to pull > it through a register to do mem-mem moves. Some instructions truely sucked, > like OUT DX,AL, where DX and AL are absolute, no operands whatsoever (ok, > there was OUT im8,AL, but that only works when you're e.g. fiddling with > keyboard lights on the PC). It takes months to learn all the opcodes and > their quirks, and after then, you'll still need the instruction set > reference. I have written a fair bit of 8086 assembly code over the years. There actually is a pattern to the instructions and which registers they must use. Whatever register you already have some valuable value in, is the one that the next instruction must mung. > I've looked at Z80 and HC11, they have nice instruction sets, rich enough to > do things with, not so burdensome that they are a pain to learn, and not so > weak that you need more for the same work. The 8051 is nice, but original > models took a whopping 12 cycles per instruction! Even the 8086 didn't go > that slow. Actually, the 8086 did go slower than that. A jump instruction on an 8086 took IIRC 21 clocks and the clock rate was only about 3MHz max. Compared to a 12MHz, this is really slow. Newer versions of the 8051 do a machine cycle on every clock. When you are flinging bytes in a 100MIPS machine, you can get a lot of bytes flung. > I understand there are streamlined versions available today, > which get as low as 1 cycle. Z80 and HC11 are in the 4 cycle range, which > isn't bad, but it's not single cycle, either. Internally, the Z80 had a 4 bit ALU that too two strokes to do each 8 bit operation. Since the fetch rate was clock/4 it wasn't a problem with speed. If you knew some of the less well documented features of the Z80, you could do lots of other things with it. There were 65536 I/O ports if you used the BC register pair version of the I/O. The refresh register could be written to so you could do some tricky DMA things that involved it. Interrupts were only checked when the refresh and interrupt vector register were on the bus. This made it possible to use the refresh register to cause semi periodic interrupts.
From: MooseFET on 20 May 2010 21:25 On May 20, 7:16 am, Jan Panteltje <pNaonStpealm...(a)yahoo.com> wrote: > On a sunny day (Thu, 20 May 2010 06:11:31 -0700 (PDT)) it happened MooseFET > <kensm...(a)rahul.net> wrote in > <ca4e547b-dded-4a76-bce3-d6c443a6e...(a)u20g2000pru.googlegroups.com>: > > > > >On May 19, 5:46 pm, "Tim Williams" <tmoran...(a)charter.net> wrote: > >> "Bitrex" <bit...(a)de.lete.earthlink.net> wrote in message > > >>news:E-ydndNy_Iic7GnWnZ2dnUVZ_gednZ2d(a)earthlink.com... > > >> > I'd love to try it out, but I'm an AVR guy - I wonder how difficult it > >> > would be to port the code to use on something like an ATMega168.... > > >> Considering how awful the PIC is, that could take a while :) > > >I always use the CDP1802 as the reference for awful instruction sets. > > > A = B + C > > >needs 16 instructions in an 1802. Compared to it, the PIC is not too > >bad. > > The PIC 18F has an 8 bit hardware multiplier > So for A7:A0 x B7:B0 -> C15:C0 > in one instruction 8052 has a MUL AB > It also has very nice compares: > cpfseq compare register F with accumulator, skip next instruction if equal > spfsgt same, but less than > cpfslt same, but greater then 8051 has the CJNE A,#5,Line500 and a DJNZ R2,Line600 For many operations, a test and jump is just one instruction > > Saves testing status register zero flag, carry, etc. > > I have used these a lot, have not used the hardware multiply, > could be nice for some filters. > > And of course all the bit set, bit clear, and bit test instructions on any register > or RAM location. > Suits me well.
From: MooseFET on 20 May 2010 21:31 On May 20, 9:59 am, D Yuniskis <not.going.to...(a)seen.com> wrote: [...] > And I could never wrap my head around the i432. Just too "radical" > for my sensibilities (at the time), I guess... :< Each instruction of the 432 was basically like this: if (I am allowed to) Memory[AddressingTable[i]] = Memory[AddressingTable[j]] + Memory[AddressingTable[k]] There was no way to directly address the memory. The machine always had to take the time to look up the address where the object was and check to see if this instruction is allowed on this instruction. [....] > It is amusing to look back and see which features became > prevalent and which *essential* as the designs evolved. > E.g., many early machines didn't support a stack. Nowadays, > even microchip has realized the benefit of this approach :-/ > (some early machines didn't support IRQ's!) The IBM-360 had no real stack but did have a store-multiple and load multiple. If you wanted to you could make a stack. > OTOH, it is disappointing to see how many peripherals have > *lost* functionality -- functionality that really isn't > costly to provide. :<
From: Joel Koltner on 20 May 2010 21:45
"MooseFET" <kensmith(a)rahul.net> wrote in message news:3eb9dc18-63bc-423c-83cf-4113b93042a1(a)k17g2000pro.googlegroups.com... On May 20, 9:59 am, D Yuniskis <not.going.to...(a)seen.com> wrote: [...] >> It is amusing to look back and see which features became >> prevalent and which *essential* as the designs evolved. >> E.g., many early machines didn't support a stack. Nowadays, >> even microchip has realized the benefit of this approach :-/ >> (some early machines didn't support IRQ's!) >The IBM-360 had no real stack but did have a store-multiple and >load multiple. If you wanted to you could make a stack. Stacks? Bah, that's way too fancy! You sure don't need them... in fact, you don't even need add instructions -- just use lookup tables, like the IBM CADETs ("Can't Add, Doesn't Even Try") did! --> http://en.wikipedia.org/wiki/IBM_1620 (...which had a *one* level stack...) I seem to recall that in early versions of FORTRAN you could redefine numeric literals as well, so that 2+2 didn't necessarily have to equal 4 anymore. :-) ---Joel |