On Thu, Jun 26, 2003 at 03:12:46AM -0500, Douglas Wood wrote:
> Then do away with the ALU completely and implement it in EPROMs. Have an
> EPROM for ADDs, another for SUBs, one for ORs, etc. Just tie the whole thing
> together with glue.

Unnecessary. Simply have one EPROM that's large enough so that you can specify
different ALU functions using the upper address range. So the inputs along
with the ALU function code make up the address to the ALU EPROM, and the output
would be the result.

The only real issue with this approach is that add and sub are really 9 bit
outputs (8 bit result + carry/borrow) and most EPROMS only have 8 output bits.
So even though it's wasteful you may need to generate a carry/borrow EPROM that
simply outputs a single carry/borrow bit based on the input and ALU function
code.

Two 8 Mbit EPROMS with a 20 bit address space would be sufficient to handle
up to 16 ALU functions. With add/sub, 4 bitwise ops, 3 logical ops, and
potentially 6 comparison operators, this space is easily filled. OTOH you could
implement the 6 comparison operators using subtract/xor and save two slots for
an add_carry and sub_borrow function code. You could then implement add with
carry out and sub with borrow out with a single EPROM.

BAJ

>
> Douglas Wood
> Software Engineer
> dbwood@kc.rr.com
> ICQ#: 143841506
>
> Home of the EPICIS Development System for the PIC
> http://epicis.piclist.com
>
> ----- Original Message -----
> From: "Brendan Moran" <annirack@SHAW.CA>
> To: <PICLIST@MITVMA.MIT.EDU>
> Sent: Thursday, June 26, 2003 2:07 AM
> Subject: Re: [EE]: ALU Enable
>
>
> > >If you're controlling the ALU simply because you don't like the idea of
> > >"messy" outputs FROM the ALU due to "messy" inputs TO the ALU, you
> probably
> > >are not building much of a CPU. There's a lot more to CPU design than the
> > >ALU.
> >
> > Ah... I'm trying to build an instruction decoder out of EPROMs... Do you
> > think this is going to be cutting edge?
> >
> > As to Peter's comments on using a pipeline, I wasn't really thinking of
> > using a pipeline initially.  I haven't done much with CPU theory or
> > design.  I've really only ever looked at existing CPUs and, frankly, I
> > honestly wouldn't know how to put the pipeline into my CPU.
> >
> > I understand pipelines in theory, but I am having a bit of trouble seeing
> > how to apply a pipeline to a stack based machine.  I mean I can see how
> > doing a 2-stage pipeline would work, (fetch next instruction during
> current
> > instruction), but beyond that, I'm not too sure.
> >
> > I'm thinking more along the lines of using microcode segments that have a
> > variable length and using a fast instruction clock so that instructions
> > take a widely varying amount of time to execute, but each instruction is
> as
> > optimized as it can be.
> >
> > I'm certain that someone here can tell me either what pipeline segments to
> > use in a stack machine or why not to use the above described technique.
> >
> > --Brendan
> >
> > --
> > http://www.piclist.com hint: PICList Posts must start with ONE topic:
> > [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
> >
>
> --
> http://www.piclist.com hint: PICList Posts must start with ONE topic:
> [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads