So: Anti software bloat
in [Design]
|
From: MooseFET on 21 May 2010 09:25 On May 20, 6:45 pm, "Joel Koltner" <zapwireDASHgro...(a)yahoo.com> wrote: > "MooseFET" <kensm...(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 programmed an ATT DSP which had a stack for one level and a built in "DO" loop instruction. There were interrupts but you'd better not use the "DO" inside them. In the main line code, the advantage was that the next instruction to be fetched would be the top of the loop again if you were looping. > > 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. :-) Fortran was a "pass by reference" language. It made it possible to some serious optimizations but it also means that the literal constant was only the initial value. If you passed 1.0 to a subroutine that changed it, the changed value was what was in memory from then on. In the IBM360 case, the Fortran passed the address of the address list. Since the 360 could address up to 4K beyond a base register, the list of addresses could be selected from with just one instruction and the value loaded on the next. There was a very interesting optimizing compiler for Fortran that could in some cases optimize your program completely out of existence. If you wrote a program that just computed the sqrt(2.0) and printed it, your program would be replaced with one that basically was: print("1.414") The optimizer knew that the sqrt(), sin() cos() etc of a constant was a constant and that the formatted printing of a constant was a fixed string. > > ---Joel
From: MooseFET on 21 May 2010 09:29 On May 20, 8:10 pm, D Yuniskis <not.going.to...(a)seen.com> wrote: > 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. Since it involves a lookup, I would expect it to be worse with todays technology. ALUs have sped up a lot more than memories. The ALU would end up waiting on the table look up. [....] > > 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. The PDP-8 stored the return address into the word before the subroutine.
From: MooseFET on 21 May 2010 09:33 On May 20, 10:38 pm, Paul Keinanen <keina...(a)sci.fi> wrote: > On Thu, 20 May 2010 18:31:46 -0700 (PDT), MooseFET > > <kensm...(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 :-). It is part of the same sort of brain dead concept group. The 286 was faster than the 432 because it used less of it. If they had instead put all those transistors to good use, they could have got about twice the throughput. > 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 :-). The PDP-8 was in many ways a nice machine. It got a lot done per transistor.
From: MooseFET on 21 May 2010 09:38 On May 21, 12:30 am, D Yuniskis <not.going.to...(a)seen.com> wrote: > Hi Paul, > > > > Paul Keinanen wrote: > > On Thu, 20 May 2010 18:31:46 -0700 (PDT), MooseFET > > <kensm...(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. No, the 432 would be worse today than back then. Memory accesses haven't kept up with ALUs adding all those extra table lookups is just a very bad idea. [....] > I'm particularly *fond* of recursive solutions! :> > And, in addition to re-entrant code, I often write > self-modifying code! ;-) I am usually coding for a machine where the code is stored in FLASH or the like so self modifying code is just not an option. Many people don't like self modifications but seem not to understand that the ability to write into a variable is just as dangerous as a GOTO or self modification.
From: MooseFET on 21 May 2010 09:45
On May 21, 1:41 am, Martin Brown <|||newspam...(a)nezumi.demon.co.uk> wrote: [....] > 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. A flat address space doesn't mean that you can't defend the code against attack. Harvard has the problem that you often end up with two versions of your subroutines. Since a store into memory and a jump are moderately rare operations, it is not much of a problem to check the protection level of the location on those operations. If you have address space to burn, you can put the code in the lower half and the variables in the upper and prevent the operations you don't want with some simple logic. This makes it Harvard like. |