Re: Misc instruction sets

["Robert J. Brown" <rj@xxxxxxxxxxxxxx>]

>>>>> "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
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.

    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.

    Wayne> Well thats it, and by the way how is the New Boards for the
    Wayne> Mup21 comming along, and what is happening with the other
    Wayne> Chips (F21 say) at the moment?

    Wayne> Wayne Morellini waynem1@cq-pan.cqu.edu.au Microsun --

-- 
-----------  "...  And the men went up and viewed Ai."  [Jos 7:2]  -----------
Robert Jay Brown III  rj@eli.wariat.org  http://eli.wariat.org  1 847 705-0370
Elijah Laboratories Inc;  759 Independence Drive;  Suite 5;  Palatine IL 60074
-----  M o d e l i n g   t h e   M e t h o d s   o f   t h e   M i n d  ------