home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.pascal.borland      Borland Pascal was actually pretty neat      2,978 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 1,862 of 2,978   
   Skybuck Flying to Marco van de Voort   
   Re: The variable bit cpu   
   03 Aug 05 09:08:53   
   
   From: nospam@hotmail.com   
      
   "Marco van de Voort"  wrote in message   
   news:slrndeu8i8.24i8.marcov@snail.stack.nl...   
   > On 2005-08-01, Skybuck Flying  wrote:   
   > >> > The cpu starts reading data and meta bits until it reaches a meta bit   
   of   
   > > 1.   
   > >>   
   > >> (ignoring the obvious "what is the (B)Pascal angle?" for a moment)   
   > >>   
   > >> "scanning" is to my best knowledge not easily paralellisable. Hence   
   your   
   > >> proposal would already lead to severe performance degradation.   
   > >   
   > > Assuming each individually bit can be addressed, scanning would not even   
   be   
   > > necessary.   
   >   
   > If you have datafields larger than the wordsize it would.   
   >   
   > > 1 Hole plugged.   
   >   
   > Nope:-)   
   >   
   > >>   
   > >> Some other reasons:   
   > >> - memory use would double.   
   > >   
   > > True, but ok... a more efficient coding could even plug this hole.   
   >   
   > No. It would lessen it at best. Moreover, if the avg size of your fields   
   > is low (e.g. bitpacked), it won't help that much.   
   >   
   > >> - what if I have more metabits than register width? IOW what if I try   
   to   
   > > load   
   > >>  a 64-bit value on a 16-bit cpu?   
   > >   
   > > A 1 bit cpu can solve it.   
   >   
   > Only for certain values it is prepared to handle. Not for _all_ values.   
   And   
   > the whole idea was being able to handle values that normally cannot be   
   handled.   
   >   
   > > Why not a 16 bit cpu.   
   > >   
   > > Pretty simply really, a sliding register etc.   
   >   
   > For addition/subtraction that works. For division/multiplication this is   
   > costly. This is the reason why most CPUs don't support these operations   
   > for more than twice the wordsize (and even that with modifications)   
   >   
   > >> - If I per accident give only zeroes as meta, what would happen?   
   > >   
   > > Don't do that ;)   
   >   
   > Note acceptable.   
   >   
   > > Add some nice error checking :)   
   >   
   > And then what? If you add a high bound, you are limiting your architecture   
   > again, just the thing you want to avoid.   
   >   
   > >> P.s. I'm no electrical engineer. If I can shoot so many obvious holes   
   in   
   > > your reasoning,   
   > >> you don't even want to know what an EE could do :_)   
   > >   
   > > So far all holes plugged... bring on them holes ! :)   
   >   
   > IMHO you showed that the performance impact can be less than 100%. That's   
   all,   
   > and was not really new to me.   
      
   Well it's clear from this post you don't believe in this idea and you are   
   trying to find any little damn excuse to diss it.   
      
   That's not how innovation works.   
      
   There are many things unknown which need to be figured out.   
      
   But I am confident that I can build a CPU with this encoding like it truely   
   hasn't been done before.   
      
   People keep saying it's done before. I have looked at every single example   
   they showed me and nope it's not be done before.   
      
   Every example is fixed bit math etc... and fixed bit registers, integers   
   etc.   
      
   There are some machines that come close. The closest so far was the IBM   
   1401.   
      
   However nothing is garantueed in life... it might fail after all...   
      
   But that's a risk I am willing to take :)   
      
   Bye,   
     Skybuck :)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca