Re[2]: MISC-d Digest V99 #105

[sz <sz@xxxxx>]

Hello Wayne,

ñðåäà, 29 äåêàáðÿ 1999 ã., you wrote:

WM> I'll answer some of the questions because you have been so helpful before,
WM> and not so many people are using the list now a days.

Thank you in return. ;)

WM>   I've discussed some of F21 features in our Russian FIDOnet
WM>   conference and my opponent points me that F21 works at 100MHz
WM>   because it can't get faster in 0.35 technology. As far as I remember
WM>   it's untrue. Am I right?

WM> You are right the 100Mhz was either for the p21 1.2 or .8 micron, or the
WM> speed running from dram  (due to pad power up time limitations in the memory
WM> interface).  I do wish they (Chuck's misc cpu's) would move to DDR-ram,
WM> SDRAM or SRAM, but that is probably financially out of reach now.   What is
WM> the transistor count for pure  F21 command execution core?  Good question,
WM> everything was supoosed to be less than 15,000 tranistores, maybe less than
WM> 9000, based on the old p21.

Ok, I was right. I was not right about .8 micron. That's even better.
(we were faiting comparing 700 MHz Alpha AXP on .35 and F21;)

WM>   Also, what is real state of stack computers?

WM> ? Usefull for tasks that don't require existing register CPU, and leading
WM> edge.

Well, I have some idea for "leading edge". I'll explain it in another
letter (answering one from Joe Zott <jaz@itvc.com>).

WM>   Why mainstream goes
WM>   register CPU? Because stacks are slower to access, or because
WM>   mainstream did not develop suitable technology to handle stacks?
WM> Why go Microsoft, PC, BMX bikes, BMW/Citroen CV2, western Qwerty Keyboard
WM> etc = fashion, right place, right time etc and being stuck with it.

Ok, I prefer to think that they're too lazy for stack comps. ;)

WM> Best regards,
WM> sz                          mailto:sz@uc.ru

WM> Merry Christmas and a happy new Mellenium (or Y2KB experience for those in
WM> system admin;) to you sz and all Miscers.

WM> Wayne

WM> P.S. sz calculate that only 1-2 cycles are needed to render each pixel in
WM> voxels, with *8 that much for photo realism.  I suggest that you stick with
WM> voxels, maybe usefull for a MISC extension, or with programmable silicon a
WM> hardware accelerator.
Really it's not true. Voxels are very uniform to process and can be
parallelized to the bones - that's true. And time required to render
single pixel depends only on someone's ability to parallelize and
uniform. ;)

Some of my recent thoughts about this thing include use of distance to
planes for clipping (then it really requires additions and division by
2), use of "test results flags" which can help eliminate needless
computation during clipping and use of quadratic or cubic interpolation
when calculating voxel size and screen coordinates. If you or anyone
else are interested - well, I'll be glad to tell more.


Buy!
 sz                            mailto:sz@uc.ru