So: Anti software bloat
in [Design]
|
From: D Yuniskis on 20 May 2010 23:10 MooseFET wrote: > 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. Yes, they tried to make everything an "object". It was too wacky thinking for the time. I suspect it would still be too inefficient even with today['s technology. >> 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. That was true of lots of machines. E.g., BAL on old PDP's. If you look at *big* machines (like the 360 -- I was initially limiting my discussion to just MCU's), there were some really clever architectures "in days past" (e.g., some of the "self timed" modules in Burroughs machines). Amusing given the problems logic had "back then". >> OTOH, it is disappointing to see how many peripherals have >> *lost* functionality -- functionality that really isn't >> costly to provide. :<
From: Paul Keinanen on 21 May 2010 01:38 On Thu, 20 May 2010 18:31:46 -0700 (PDT), MooseFET <kensmith(a)rahul.net> wrote: >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. Sounds just like an extension of the 80286 segment concept with a separate segment descriptor for each object :-). However, IBM had success with S/38 and later AS/400 systems that had also somewhat similar object protection model. >[....] >> 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. � Who needs stacks, when the function return address is stored at the function label and the return from that function was just an indirect jump through that label :-). Who needs recursion or re-entrant code :-). >>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: D Yuniskis on 21 May 2010 03:30 Hi Paul, Paul Keinanen wrote: > On Thu, 20 May 2010 18:31:46 -0700 (PDT), MooseFET > <kensmith(a)rahul.net> wrote: > >> 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. > > Sounds just like an extension of the 80286 segment concept with a > separate segment descriptor for each object :-). > > However, IBM had success with S/38 and later AS/400 systems that had > also somewhat similar object protection model. I think the 432 was just *way* too far ahead of the curve. Sort of like the "registers in memory" that the 99K used. Clever idea but just didn't make the cut. >>> 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. > > Who needs stacks, when the function return address is stored at the > function label and the return from that function was just an indirect > jump through that label :-). > > Who needs recursion or re-entrant code :-). I'm particularly *fond* of recursive solutions! :> And, in addition to re-entrant code, I often write self-modifying code! ;-) Yum, yum!
From: Martin Brown on 21 May 2010 04:41 On 21/05/2010 08:30, D Yuniskis wrote: > Hi Paul, > > Paul Keinanen wrote: >> On Thu, 20 May 2010 18:31:46 -0700 (PDT), MooseFET >> <kensmith(a)rahul.net> wrote: >> >>> 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. >> >> Sounds just like an extension of the 80286 segment concept with a >> separate segment descriptor for each object :-). >> >> However, IBM had success with S/38 and later AS/400 systems that had >> also somewhat similar object protection model. > > I think the 432 was just *way* too far ahead of the curve. > Sort of like the "registers in memory" that the 99K used. > Clever idea but just didn't make the cut. You needed expensive fast local cache memory to make it fly, but I have to defend the honour of the 99k (and the older 9900 series that had the same architecture). I didn't realise quite how good it was at context switching until later when we ported the same functionality onto 68k hardware. Though on paper the 68k was quicker the 99k could beat it. And hardly anyone even remembers poor old captain Zilogs Z8000 now. ISTR Ollivetti were about the only ones to make PCs M20s with it in. > >>>> 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. >> >> Who needs stacks, when the function return address is stored at the >> function label and the return from that function was just an indirect >> jump through that label :-). >> >> Who needs recursion or re-entrant code :-). > > I'm particularly *fond* of recursive solutions! :> > And, in addition to re-entrant code, I often write > self-modifying code! ;-) > > Yum, yum! Generally a bad idea. For security I favour Harvard architecture. Complete separation of code and data spaces prevents a lot of common forms of attack against system integrity. Flat linear address spaces which are in vogue now may one day be seen as a very bad idea. Regards, Martin Brown
From: JW on 21 May 2010 05:33
On Thu, 20 May 2010 18:19:18 -0700 (PDT) MooseFET <kensmith(a)rahul.net> wrote in Message id: <66d63767-f13a-4637-afe7-7b2258ac5641(a)42g2000prb.googlegroups.com>: >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. IIRC, the Intel 8086 topped out at 10MHz. AMD and NEC may have had faster versions. |