So: Anti software bloat
in [Design]
|
From: Paul Keinanen on 22 May 2010 04:42 On Fri, 21 May 2010 06:38:01 -0700 (PDT), MooseFET <kensmith(a)rahul.net> wrote: >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. One reason for the popularity of self modifying code in the old days was simply the lack of usable addressing modes. Lack of index registers or bad indirect addressing support often forced to modify the effective address part of the instruction, in order to go through each element in a table.
From: Jan Panteltje on 22 May 2010 06:03 On a sunny day (Fri, 21 May 2010 20:09:49 -0700) it happened Robert Baer <robertbaer(a)localnet.com> wrote in <GZKdnaQfNKZs12rWnZ2dnUVZ_rmdnZ2d(a)posted.localnet>: >> Now there is free code space, free code space free code space, whatshallwedo with the free code space? >> I have some idea. >> >> > If you are to compete with M$, you _must_ have software bloat!!! > The more bloat, the better the competition! Well, there is a trend towards sanity happeing (at least I hope so). mainly drive by cellphones and other the like devices. Now if they could only kill those Java snails... I think MS realised[D[D[D[ that, or at least somebody there has noticed the writing on the wall. Within the shortest time the smallest device will be able to do anything Big Bloat Billy can, for less money, with more speed, and less resources, more stability, and without those idiotic auto updates that refuse to switch of your PC because they are installing new bugs. That is why I burned my xp disk, all of the above.
From: MooseFET on 22 May 2010 10:17 On May 22, 12:44 am, Paul Keinanen <keina...(a)sci.fi> wrote: > On Fri, 21 May 2010 06:29:43 -0700 (PDT), MooseFET > > > > <kensm...(a)rahul.net> wrote: > >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. > > Current virtual memory machines have dedicated translation buffers, > these TLBs work just like caches. In normal operation, most virtual to > physical address translations are done in TLBs and only occasionally > there would be a miss and a new table partition needs to be loaded > from main memory. > > In the same way, the i432 addressing could work quite effectively > these days. The 432 would still need an extra cycle or it would have to have a huge amount of extra hardware to make the translated version of the address table. The number of elements in the translation table would be far higher than the number of elements in the TLBs. Virtual memory works with pages much larger than just one floating point value. This would make the accesses slower because the speed of memory tends to fall as the sqrt() of the size. The ALU would end up waiting on all these extra actions and delays. There are good reasons that nobody has gone back to the idea. > > With suitable caching, the TMS9900 style "register set in memory" > would also quite effective these days. Registers maps to a linear chunk of memory could be made to work. For most of the operation, the machine would actually work like ones that don't map the registers to RAM. Only if an access happens to hit the part that is mapped to the registers does anything special need to happen.
From: Didi on 22 May 2010 12:08 On May 22, 5:17 pm, MooseFET <kensm...(a)rahul.net> wrote: > ..... > > With suitable caching, the TMS9900 style "register set in memory" > > would also quite effective these days. > > Registers maps to a linear chunk of memory could be made to work. > For most of the operation, the machine would actually work like > ones that don't map the registers to RAM. Only if an access > happens to hit the part that is mapped to the registers does > anything special need to happen. The 54xx DSPs of TI have a memory-mapped set of registers (but not all, e.g. the 40 bit accumulators are not). Quite efficient, as they are mapped in dual-access memory (two accesses per cpu cycle), it's been a while since I did the assembler for it and wrote stuff but I have no memory of any limitations because of that. In fact I think I could at some point take advantage of the fact the registers could be accessed also this way (with all the pipeline delay implications etc., but I think I did use that for something). Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
From: D Yuniskis on 22 May 2010 17:15
Hi Paul, Paul Keinanen wrote: > On Fri, 21 May 2010 06:29:43 -0700 (PDT), MooseFET > <kensmith(a)rahul.net> wrote: > >> 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. > > Current virtual memory machines have dedicated translation buffers, > these TLBs work just like caches. In normal operation, most virtual to > physical address translations are done in TLBs and only occasionally > there would be a miss and a new table partition needs to be loaded > from main memory. Yes, but even two level TLB's are relatively few in number and a single entry covers a significant amount of memory. I think the 432 dealt with much smaller "objects" than "physical pages". > In the same way, the i432 addressing could work quite effectively > these days. > > With suitable caching, the TMS9900 style "register set in memory" > would also quite effective these days. I think it depends on how many register sets you end up using. I.e., one tends to think of register set in the context of a thread state. However, I could easily see compilers using this feature to implement small stack frames (I bet most blocks could benefit from a single "register context"!). If that's the case, you'll frequently have cache misses as you enter new blocks, etc. (of course, you will win *while* in that context... but I am not sure what the overall cost would be for those misses vs. having a register file *in* the processor.) Sounds like a good (safe) "senior project" :> |