So: Anti software bloat
in [Design]
|
From: JosephKK on 23 May 2010 18:10 On Fri, 21 May 2010 09:18:30 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >Hi Martin, > >Martin Brown wrote: >> On 21/05/2010 08:30, D Yuniskis wrote: >>> 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 > >Correct. Since you want to be able to more the set of working >registers *anywhere*, it has to be a real cache and not just >"a region of fast memory". This adds to the complexity of the >system (hardware) at a time when MCU's were getting *cheaper* >to deploy. > >> 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. > >The military liked the Z8000. > >After the Z80, Zilog couldn't do *anything* right! (88000, Z800, >Z280, etc.) The 88000 was a Motorola attempt at a RISC machine. > >>>>>> 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. > >Write good code and you don't have to worry about those >"attacks". Corrupted data leaves you just as vulnerable >to "attack" as corrupting the code space. Check all your >inputs. Know what your code really *is* doing (not what >you *hope* it's doing). |