So: Anti software bloat
in [Design]
|
From: Tim Williams on 21 May 2010 10:55 "D Yuniskis" <not.going.to.be(a)seen.com> wrote in message news:ht5cfp$12q$1(a)speranza.aioe.org... > I'm particularly *fond* of recursive solutions! :> > And, in addition to re-entrant code, I often write > self-modifying code! ;-) I wrote a tone generator for Z80 once. To generate rests (i.e., unvoiced notes), the best solution was simply: ld a,(outbit) xorbits: xor 11b ; invert output (warning: adaptive instruction) out (5),a ld (outbit),a Down where it's fetching the note/rest it says.. ld a,(outbit) and 1100b ; test zero-bits jr z,makerest ; if zero, don't play note ld a,11101110b ; XOR A,n instruction (plays note) ld (xorbits),a jr outintr makerest: ld a,11110110b ; OR A,n instruction (output remains high) ld (xorbits),a jr outintr 'Course, the whole operation is fully commented. I also did this on an x86 raycaster routine. Saves having four copies of the thing (for the four cardinal directions). It could be handy if C supported this type of construct, then again the language is obfuscated well enough on its own. Plus, lots of architectures don't allow self modifying code, or at least very quickly (cache lines, or worse yet, flash ROM for program space). Tim -- Deep Friar: a very philosophical monk. Website: http://webpages.charter.net/dawill/tmoranwms
From: D Yuniskis on 21 May 2010 12:18 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.) >>>>> 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).
From: krw on 21 May 2010 19:13 On Thu, 20 May 2010 21:51:33 +0300, Paul Keinanen <keinanen(a)sci.fi> wrote: >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. The ultimate CISC was the /360. >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: Joel Koltner on 21 May 2010 19:26 <krw(a)att.bizzzzzzzzzzzz> wrote in message news:vk4ev59cr98vv1m0dtuls2letu6bi44q6f(a)4ax.com... > Very few operations used IN/OUT. The display was memory mapped. Oh yeah, my mistake -- I was just remembering that you had your choise of "really slow text output" on the old CGA cards or "fast but with snow." But that was due to there being no mechanism to deal with the CPU and video controller both accessing video memory at once (well, other than "CPU must win for the sake of data integrity, it's OK if it snows a bit on the screen"), not IN/OUT commands. And I guess the BIOS text routines were slow as well, right? -- Everyone just bypassed them, writing directly to video memory, after a little bit? I kinda suspect that for business users the Apple IIgs might have won out over PCs if it'd been released a few years earlier. Or maybe not -- perhaps the availability of clones is what really put PCs on top... and I suppose Apple was competing with itself as well, having released the Macintosh prior to the IIgs. What computers did you have before PCs took over the world, Keith? :-) ---Joel
From: Jamie on 21 May 2010 19:35
Joel Koltner wrote: > <krw(a)att.bizzzzzzzzzzzz> wrote in message > news:vk4ev59cr98vv1m0dtuls2letu6bi44q6f(a)4ax.com... > >> Very few operations used IN/OUT. The display was memory mapped. > > > Oh yeah, my mistake -- I was just remembering that you had your choise > of "really slow text output" on the old CGA cards or "fast but with > snow." But that was due to there being no mechanism to deal with the > CPU and video controller both accessing video memory at once (well, > other than "CPU must win for the sake of data integrity, it's OK if it > snows a bit on the screen"), not IN/OUT commands. > > And I guess the BIOS text routines were slow as well, right? -- Everyone > just bypassed them, writing directly to video memory, after a little bit? > > I kinda suspect that for business users the Apple IIgs might have won > out over PCs if it'd been released a few years earlier. Or maybe not -- > perhaps the availability of clones is what really put PCs on top... and > I suppose Apple was competing with itself as well, having released the > Macintosh prior to the IIgs. > > What computers did you have before PCs took over the world, Keith? :-) > > ---Joel > I started with Punch card main frames, CBM's, Timx, CoCo, Vic 20, C-64, C&D-128 and finally, I got a Commodore IBM clone with turbo mode with a whopping 40 Meg Western Digital HD! :) |