home .. forth .. misc mail list archive ..

Re: Misc instruction sets


From: "Robert J. Brown" <rj@eli.wariat.org>
>>>>>> "Wayne" == Wayne Morellini <waynem1@cq-pan.cqu.edu.au> writes:
>
>    Wayne> Hi Sad to see that there is not much traffic on the list,
>    Wayne> is there other alternatives for news/discussion on Misc
>    Wayne> processors?
>
>You could say that the trasffic is MINIMAL.
>
>    Wayne> Anyway as I am still working on my own personal Misc
>    Wayne> component stratergy with regards to an OS, I am seeking
>    Wayne> some free advice on structure of Misc instruction sets.
>
>I am presently working with a MISC architecture designed by John
>Rible.  It only has 4 basic instruction types: memory read, memory

I also considered such a design.

>write, ALU immediate, and ALU register-to-register.  The ALU is a
>standard type with 4 mode lines to select the operation.  These lines
>are just 4 bits in the ALU instructions.  The memory instructions are
>designed to make implementing stacks easy, with auto
>increment/decrement, but there is no hardware stack per say, just
>registers that can hold addresses or data.  The architecture is
>designed to make implementing Forth really easy and fast in execution.

Where are details of this hardware available, I've been waiting for a bit to
long for a 32-bit version of stack based chip from Chuck (try 7-8 years),
and quiet frankly 20-bits now is to constricting for the applications I'm
looking at (following trends of increasing performance and smaller sizing)
becuase of the extra logic required for the intergration (not meant to be a
debate please).  Sure I could go and get an ARM 7200 or future StongArm
equivalent and archive half the cost, but such products wont provide a
Spiritual homeland for forth and stack based architechers.
 
>
>    Wayne> I have in the past worked out an suitable instruction set
>    Wayne> and am about to finish it off, of course knowing the
>    Wayne> efficencies of stack based architechers I would hope to
>    Wayne> make it stack based, but I also would like to know more
>    Wayne> about the deficencies of this stratergy?  I would also like
>    Wayne> to hear about things to do with what are the basic needed
>    Wayne> instructions, what formats produce the best speed and
>    Wayne> memory efficencies (for example maths instructions), what
>    Wayne> leads to the best speed and memory efficencies of the
>    Wayne> overall code?  For instance Intel, I beleive, spend
>    Wayne> millions of dollers on code simulation to improve the
>    Wayne> performance of their instruction set, a little bit of
>    Wayne> logical thought and discussion could do the same for Misc
>    Wayne> designs.  This would probably be of benefit for all who
>    Wayne> attend the list and the future design of misc engines.
>
>These simulations are based on the assumption of a certain kind of
>program execution as the application.  Certain workstation type
>programs are generally the kind I would expect them to try to optimize
>for.  Artificial Intelligence applications are charactarized by very
>large memory spaces, very deep recursion, and poor locality of
>reference.  These all make for a very difficult and different sort of
>application.  Programs that do well on one sort of architecture will
>typically do less well on another.  Embedded real-time applications
>such as digital filtering and signal processing require still another
>architecture.  Embedded control systems, as opposed to signal
>processing, would require still another architecture for optimal mix
>of instructions and memory cycles.  Given a particular target
>application type, it should be possible to develop a set of benchmarks
>that would permit valid performance measurement.  With such a
>benchmark set, architectures could be optimized for speed, cost,
>memory size, etc.  Simulation of actual applications in addition to
>benchmarks is a very desirable thing.  Benchmarks really serve no
>useful purpose except being pathological time trials.

Yes and they are also run on common office programs.  What I am looking at
is what is needed in most areas, and provide a miniumalist set of words to
archieve it, ie  look at Chucks innovation of the Address register in Mup
to consecuvately reference memory locations, how much time does it save over
having the adress on the stack etc.  Any help on this endeavour from anybody
out there would be most appreciated.

Wayne

--