|
Message
From: markus at reaaliaika.net<markus@r...>
Date: Tue Aug 31 14:11:30 CEST 2004
Subject: [oc] Parallel Array Processor Project
[narrow ALUs]
> You you want power, the "good width" is better. With an 8
> bits alu, you will need 4 times it for 16 bits op. Almost twice
> the ressource of a true 16 bits alu.
But 16-bit ALU would require 16-bit buses between the cells, thus
doubling the routing area... And in my plans, I think it's better to
have 2 x 8-bit independent buses than have 1 x 16-bit bus - or to have
4 x 8-bit separate data flows than single 32-bit flow.
I have tought hard for possible 5-bit implementation of the cell - 4-bits
for "raw" data (one hex nibble) and 16 different flow control instructions
(flow breaks, field breaks, "parenthesis" and so on).
> So if target DSP market, datapath of 16 or 18 bits will deliver
> "more usefull" power.
True, but general-purpose processors, like MCUs, need to deal with
almost arbitrary sized data elements, so ALU width doesn't really matter
(because it can't be the size of the largest element). Much of the MCU
programs are just plain data transfers from memory location A to
memory location B, and consecutive conditional branches ("if", "switch").
This area is definitely not the first one in anybody's mind to apply
arithmetic arrays, I know ;-D But like I stated before, the _true_
(hardware) goals are in the future, when we start to wonder, what to
do with the billions of transistors in a chip.
Of course, I wouldn't mind, if the array executing control code could be
implemented today and find to be useful. Maybe the real-world
implementation is a mix of different sized (& equipped) cells and buses?
5-bit cell arrays controlling/configuring pure 64-bit floating point
arithmetic arrays (i.e. just scalar floating point reconfigurable routes)?
[Arithmetic arrays as coprocessors]
> Such pure arythmetic array quite bad for control. But mix of cpu +
> datapath could do what you want at the beginning : create some VM
> for java or perl.
I already have VM written with Python (PMVM). In that VM, I have
passed all the hard things (like arrays and such) and concentrated only
to form instruction set.
Currently, I moved the HLL design to the future (because of having hard
times to invent good control structures) and started instead to
implement a "toy" HLL and during that I implement a VM of even higher
level to test the concept.
ToyHLL isn't meant to be complete or something like that, it's aimed to
be a test platform for control structures and easy to use for
constructing "PM-like" software.
|
 |
Browse
