Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #41540 > unrolled thread

Forth CPUs with NO Interrupts

Back to article view | Back to comp.lang.forth

Contents

  Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-08-26 00:53 -0400
    Re: Forth CPUs with NO Interrupts anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-26 08:51 +0000
      Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-08-26 08:50 -0400
      Re: Forth CPUs with NO Interrupts "Elizabeth D. Rather" <erather@forth.com> - 2015-08-26 07:23 -1000
    Re: Forth CPUs with NO Interrupts Mark Wills <markwills1970@gmail.com> - 2015-08-26 04:33 -0700
      Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-08-26 08:46 -0400
      Re: Forth CPUs with NO Interrupts mhx@iae.nl - 2015-08-26 11:17 -0700
      Re: Forth CPUs with NO Interrupts hughaguilar96@gmail.com - 2015-08-26 12:50 -0700
        Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-08-26 18:28 -0400
      Re: Forth CPUs with NO Interrupts hughaguilar96@gmail.com - 2015-08-27 23:44 -0700
        Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-08-28 18:28 -0700
    Re: Forth CPUs with NO Interrupts Walter Banks <walter@bytecraft.com> - 2015-08-26 11:41 -0400
    Re: Forth CPUs with NO Interrupts Syd Rumpo <usenet@nononono.co.uk> - 2015-08-26 17:12 +0100
      Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-08-26 09:48 -0700
      Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-08-26 18:39 -0400
    Re: Forth CPUs with NO Interrupts "Ala'a Alawi" <amalawi@gmail.com> - 2015-08-27 08:37 -0700
    Re: Forth CPUs with NO Interrupts pbjtech@gmail.com - 2015-08-30 19:01 -0700
      Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-08-30 22:45 -0400
        Re: Forth CPUs with NO Interrupts Reinhardt Behm <rbehm@hushmail.com> - 2015-08-31 11:09 +0800
      Re: Forth CPUs with NO Interrupts hughaguilar96@gmail.com - 2015-08-30 20:06 -0700
        Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-08-30 23:20 -0400
          Re: Forth CPUs with NO Interrupts hughaguilar96@gmail.com - 2015-09-02 14:14 -0700
            Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-02 18:02 -0400
        Re: Forth CPUs with NO Interrupts Bob <bob@none.com> - 2015-08-31 20:49 -0400
          Re: Forth CPUs with NO Interrupts Mark Wills <markwills1970@gmail.com> - 2015-09-01 01:39 -0700
            Re: Forth CPUs with NO Interrupts dunno <dunno@dunno.dunno> - 2015-09-01 17:58 +0000
            Re: Forth CPUs with NO Interrupts Bob <bob@none.com> - 2015-09-01 18:48 -0400
              Re: Forth CPUs with NO Interrupts hughaguilar96@gmail.com - 2015-09-01 16:32 -0700
              Re: Forth CPUs with NO Interrupts Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-02 01:38 +0200
                Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-01 22:09 -0400
                  Re: Forth CPUs with NO Interrupts Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-02 14:12 +0200
                    Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-02 12:40 -0400
                      Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-09-02 10:40 -0700
                        Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-02 16:57 -0400
                          Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-09-02 14:55 -0700
                            Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-02 18:11 -0400
                              Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-09-02 16:20 -0700
                                Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-02 20:42 -0400
                                  Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-09-02 22:34 -0700
                                    Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-03 12:59 -0400
                                      Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-09-03 15:54 -0700
                                        Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-03 19:54 -0400
                                          Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-09-03 21:13 -0700
                                            Re: Forth CPUs with NO Interrupts Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-09-04 09:48 +0100
                                              Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-09-04 08:49 -0700
                                                Re: Forth CPUs with NO Interrupts hughaguilar96@gmail.com - 2015-09-04 11:15 -0700
                                                  Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-04 14:32 -0400
                                                    Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-09-04 11:36 -0700
                                                      Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-04 17:46 -0400
                                            Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-04 11:47 -0400
                                              Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-09-04 09:20 -0700
                                                Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-04 12:52 -0400
                                                  Re: Forth CPUs with NO Interrupts Mux <Yvo.Zoer@gmail.com> - 2015-09-04 10:20 -0700
                      Re: Forth CPUs with NO Interrupts Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-02 23:35 +0200
                        Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-02 18:09 -0400
                          Re: Forth CPUs with NO Interrupts Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-03 02:07 +0200
                            Re: Forth CPUs with NO Interrupts rickman <gnuarm@gmail.com> - 2015-09-02 20:49 -0400
                              Re: Forth CPUs with NO Interrupts Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-03 14:30 +0200
      Re: Forth CPUs with NO Interrupts hughaguilar96@gmail.com - 2015-09-02 14:23 -0700

Page 3 of 3 — ← Prev page 1 2 [3]

#41711

> Yes and very inefficient in terms of logic utilization.  A high price to 
> pay for performance which may or may not pan out.  I find the block RAMs 
> are not in any of the critical timing paths of any CPU I've designed.
> 
> -- 
> 
> Rick

How is that inefficient if it's one LE per bit? As far as performance goes, it's well into the 200mhz performance range which is fast enough for me on a cheap FPGA. I'm not looking into spending $$$ to get FPGA's in the Ghz range. Anything that runs at about 50-100mhz will do nicely for me..

-Y

[toc] | [prev] | [next] | [standalone]

#41713

On 9/3/2015 6:54 PM, Mux wrote:
>> Yes and very inefficient in terms of logic utilization.  A high price to
>> pay for performance which may or may not pan out.  I find the block RAMs
>> are not in any of the critical timing paths of any CPU I've designed.
>>
>> --
>>
>> Rick
>
> How is that inefficient if it's one LE per bit? As far as performance goes, it's well into the 200mhz performance range which is fast enough for me on a cheap FPGA. I'm not looking into spending $$$ to get FPGA's in the Ghz range. Anything that runs at about 50-100mhz will do nicely for me..

Not one LE per bit, one LE per bit per register.  If you are working in 
a part where you have lots of LEs to use, fine.  My CPU design uses 600 
LUTs total plus 1 block RAM for both stacks (not 1 each) and whatever 
data/program memory you need to use.  Using 256 LUTs for the stack 
registers seems like a poor tradeoff to me, but it all depends on what 
you have lots of.

Does your entire CPU run at 200 MHz?  The decode must be very simple.  I 
take it you have a zero compare instruction rather than flags?  What 
about detecting carry or overflow?  Those are the speed critical paths 
in my design.  In a 15 year old Altera FPGA it ran at 50 some MHz.  I 
only ever had one application for it though, so I spent a little time 
looking at improvements, but never worked with it further.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#41714

> Not one LE per bit, one LE per bit per register.  If you are working in 
> a part where you have lots of LEs to use, fine.  My CPU design uses 600 
> LUTs total plus 1 block RAM for both stacks (not 1 each) and whatever 
> data/program memory you need to use.  Using 256 LUTs for the stack 
> registers seems like a poor tradeoff to me, but it all depends on what 
> you have lots of.
> 
Correct. One LE per bit per register. The EPF10k10 has 576 LE's and with both the data- and return stack being 8 deep (256LE's) and the remaining logic coming in at around ~100 LE's that leaves ample space for other things. The 10k10 only has 6144 bits of memory that I need for line-buffers and palettes. So yeah, it's a trade-off.

> Does your entire CPU run at 200 MHz?  The decode must be very simple.  I 
> take it you have a zero compare instruction rather than flags?  What 
> about detecting carry or overflow?  Those are the speed critical paths 
> in my design.  In a 15 year old Altera FPGA it ran at 50 some MHz.  I 
> only ever had one application for it though, so I spent a little time 
> looking at improvements, but never worked with it further.

Yup. The instructions are 4-bit each, which means I can fetch 4 of them at once. A '0=' instruction is used to for checking for zero (obviously) and consists of nothing more than at 16-way OR rather than a compare. no overflow or carry. Registered performance hovers somewhere around 200mhz with a tpd hovering around ~125mhz. Nice thing is that it also has a single interrupt (like I stated earlier) source as well as a pre-fetch for the next 4-instructions from memory, based on some of the work from Eric La-Forest.

On a somewhat different note,I don't particularly care for the hostilities in this- and other threads, or any on CLF. Not singling out anyone in particular but the bitch-fests that I've seen on this group far outweigh the actual useful posts where people actually try to help one-another.

Just an observation...

-Y

[toc] | [prev] | [next] | [standalone]

#41720

On Thu, 3 Sep 2015 21:13:50 -0700 (PDT)
Mux <Yvo.Zoer@gmail.com> wrote:


> > 
> Correct. One LE per bit per register. [...]

Thanks for the details, I'm very interested in practical work
on FPGA stack engines, especially using tiny low power devices. 


> On a somewhat different note,I don't particularly care for the
> hostilities in this- and other threads, or any on CLF. Not
> singling out anyone in particular but the bitch-fests that
> I've seen on this group far outweigh the actual useful posts
> where people actually try to help one-another.
> 
> Just an observation...

It's a big problem, with noise often outweighing signal. I try
to avoid responding when when threads get set in treacle.

Jan Coombs
-- 
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk

[toc] | [prev] | [next] | [standalone]

#41726

> > On a somewhat different note,I don't particularly care for the
> > hostilities in this- and other threads, or any on CLF. Not
> > singling out anyone in particular but the bitch-fests that
> > I've seen on this group far outweigh the actual useful posts
> > where people actually try to help one-another.
> > 
> > Just an observation...
> 
> It's a big problem, with noise often outweighing signal. I try
> to avoid responding when when threads get set in treacle.
> 
> Jan Coombs
> -- 

I think a bigger problem is that it sends a message to people new to forth that this is / can be a pretty hostile group, which turns a lot of people off. If we ever want to engage and encourage people to pick up forth, we need to be more welcoming and be open to new ideas without being prejudice. 

-Y

[toc] | [prev] | [next] | [standalone]

#41731

On Friday, September 4, 2015 at 8:49:31 AM UTC-7, Mux wrote:
> > > On a somewhat different note,I don't particularly care for the
> > > hostilities in this- and other threads, or any on CLF. Not
> > > singling out anyone in particular but the bitch-fests that
> > > I've seen on this group far outweigh the actual useful posts
> > > where people actually try to help one-another.
> > > 
> > > Just an observation...

> > It's a big problem, with noise often outweighing signal. I try
> > to avoid responding when when threads get set in treacle.
> > 
> > Jan Coombs
> > -- 
> 
> I think a bigger problem is that it sends a message to people new to forth that this is / can be a pretty hostile group, which turns a lot of people off. If we ever want to engage and encourage people to pick up forth, we need to be more welcoming and be open to new ideas without being prejudice. 

According to Google, treacle is defined as: "cloying sentimentality or flattery."

I used to say that ANS-Forth was a castle built on sand --- but now I would describe it as a castle built on treacle!

The Elizabeth Rather cult were the architects of their own ruin, and for mortar they used treacle...

[toc] | [prev] | [next] | [standalone]

#41732

On 9/4/2015 2:15 PM, hughaguilar96@gmail.com wrote:
> On Friday, September 4, 2015 at 8:49:31 AM UTC-7, Mux wrote:
>>>> On a somewhat different note,I don't particularly care for the
>>>> hostilities in this- and other threads, or any on CLF. Not
>>>> singling out anyone in particular but the bitch-fests that
>>>> I've seen on this group far outweigh the actual useful posts
>>>> where people actually try to help one-another.
>>>>
>>>> Just an observation...
>
>>> It's a big problem, with noise often outweighing signal. I try
>>> to avoid responding when when threads get set in treacle.
>>>
>>> Jan Coombs
>>> --
>>
>> I think a bigger problem is that it sends a message to people new to forth that this is / can be a pretty hostile group, which turns a lot of people off. If we ever want to engage and encourage people to pick up forth, we need to be more welcoming and be open to new ideas without being prejudice.
>
> According to Google, treacle is defined as: "cloying sentimentality or flattery."
>
> I used to say that ANS-Forth was a castle built on sand --- but now I would describe it as a castle built on treacle!
>
> The Elizabeth Rather cult were the architects of their own ruin, and for mortar they used treacle...

Mux, how would you recommend handling Beetlejuice?

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#41733

> Mux, how would you recommend handling Beetlejuice?

I might be somewhat out of the loop.. Who's considered Beetlejuice?

-Mux

[toc] | [prev] | [next] | [standalone]

#41737

On 9/4/2015 2:36 PM, Mux wrote:
>> Mux, how would you recommend handling Beetlejuice?
>
> I might be somewhat out of the loop.. Who's considered Beetlejuice?

It's my pet name for Hugh.  One way to get him to post is to mention his 
name.  Not that I am trying to do that...

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#41725

On 9/4/2015 12:13 AM, Mux wrote:
>> Not one LE per bit, one LE per bit per register.  If you are
>> working in a part where you have lots of LEs to use, fine.  My CPU
>> design uses 600 LUTs total plus 1 block RAM for both stacks (not 1
>> each) and whatever data/program memory you need to use.  Using 256
>> LUTs for the stack registers seems like a poor tradeoff to me, but
>> it all depends on what you have lots of.
>>
> Correct. One LE per bit per register. The EPF10k10 has 576 LE's and
> with both the data- and return stack being 8 deep (256LE's) and the
> remaining logic coming in at around ~100 LE's that leaves ample space
> for other things. The 10k10 only has 6144 bits of memory that I need
> for line-buffers and palettes. So yeah, it's a trade-off.
>
>> Does your entire CPU run at 200 MHz?  The decode must be very
>> simple.  I take it you have a zero compare instruction rather than
>> flags?  What about detecting carry or overflow?  Those are the
>> speed critical paths in my design.  In a 15 year old Altera FPGA it
>> ran at 50 some MHz.  I only ever had one application for it though,
>> so I spent a little time looking at improvements, but never worked
>> with it further.
>
> Yup. The instructions are 4-bit each, which means I can fetch 4 of
> them at once. A '0=' instruction is used to for checking for zero
> (obviously) and consists of nothing more than at 16-way OR rather
> than a compare. no overflow or carry. Registered performance hovers
> somewhere around 200mhz with a tpd hovering around ~125mhz.

You lost me there.  What do you mean tpd?  Are you talking about the 
useful I/O rate?


> Nice
> thing is that it also has a single interrupt (like I stated earlier)
> source as well as a pre-fetch for the next 4-instructions from
> memory, based on some of the work from Eric La-Forest.

Is your memory external?  I've never gone that route since my uses for 
internal CPUs are always 100% internal.  I typically don't have room on 
the board for an external memory or the design is a retrofit where there 
was none in the first place.  Prefetching doesn't speed up a CPU running 
from internal memory since the block RAM is nearly as fast as a register.

BTW, what are your 4 bit instructions?  I've never been able to convince 
myself such a small instruction is the way to go.  Just as stack ISAs 
generate a fair percentage of code to thrash the stack, small 
instructions exacerbate this with the very few instructions possible. 
I'm wondering if VLIW isn't the way to go for stack machines.  But then 
the tools get more complex to optimize the parallelism or the user has 
to figure it all out themselves.


> On a somewhat different note,I don't particularly care for the
> hostilities in this- and other threads, or any on CLF. Not singling
> out anyone in particular but the bitch-fests that I've seen on this
> group far outweigh the actual useful posts where people actually try
> to help one-another.
>
> Just an observation...

I hope you aren't referring to my posts.  I try to avoid confrontation, 
but know I push Hugh's buttons sometimes.  I also get into "discussions" 
with Bernd sometimes that are less than productive.  I was surprised 
that a recent interaction with Hugh started to go in a semi-useful 
direction for a moment.  If I am crossing lines I would like for someone 
to tell me, but I expect it is hard to know where the line is in this 
group.  At least it isn't s.e.d where anything goes, including 
references to Nazis, lol.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#41728

> Is your memory external?  I've never gone that route since my uses for 
> internal CPUs are always 100% internal.  I typically don't have room on 
> the board for an external memory or the design is a retrofit where there 
> was none in the first place.  Prefetching doesn't speed up a CPU running 
> from internal memory since the block RAM is nearly as fast as a register.
> 
Memory is external. 64kx16 static ram at 10ns which allows me to do pre-fetching if the last instruction isn't referencing memory. Check out Eric La-Forests paper for more info.

> BTW, what are your 4 bit instructions?  I've never been able to convince 
> myself such a small instruction is the way to go.  Just as stack ISAs 
> generate a fair percentage of code to thrash the stack, small 
> instructions exacerbate this with the very few instructions possible. 

Yup. It's taking MISC to an absolute level but it kinda works. See if I can remember... PC@,LIT,+,AND,XOR,2/,0=,DUP,DROP,OVER,PUSH,POP,@,!,JUMP,CALL.

From Eric's paper, PC@ is an instruction that literally fetches the next 4 instructions. While that does mean an extra clock per every 4 instructions, most of the time the prefetcher manages to avoid it. Given that you generally need more stack operations, this increases the frequency the prefetcher is able to kick in. As Eric mentioned, it's a really elegant solution as it gets automatically shifted in (all zeroes) and thus becomes the '5th' instruction, which is why it's coded as 0. Ting's 4-bit CPU and others use a 2-bit instruction counter and a nop, which means you have to NOP out your IR and stall rather than early-out.

The interrupt mechanism, which happens when a PC@ is about to execute, is basically a mux that either gates { DUP,DUP,XOR,CALL } or the next instruction word from memory and calls address 0, which has code that determines how it got there (i.e. interrupt bit set -> interrupt ). 

Jump is conditional and works closely with 0= to mask off addresses. A side effect is that you can never jump to zero, which is fine. Exit is encoded as { pop, jump }.

Call on the other hand IS able to jump to zero and therefore allows me to generate a call without referencing memory and hardwiring reset/irq to the same address.

One last thing is that LIT is the only instruction that references memory. So jump / call first put the address on the datastack. Mainly did this to simplify stuff.

4-bits is really pushing it but it was an interesting exercise / experiment to see what you can do. Code density is reasonably high in places but, as you stated already, you end up with more instructions to do the same. To that extent, I'm currently working on a new 5-bit CPU :-)

Btw, if anyone's interested I can post my verilog code on OpenCores.

> I'm wondering if VLIW isn't the way to go for stack machines.  But then 
> the tools get more complex to optimize the parallelism or the user has 
> to figure it all out themselves.
> 

Thing with VLIW is that you have a lot of unused units sitting idle that takes up space. I remember working on VMLabs' Nuon which had a theoretical '28 instructions per clock' spread out over 4 cores. Died a horrible death but was a pretty neat architecture at the time.

> 
> > On a somewhat different note,I don't particularly care for the
> > hostilities in this- and other threads, or any on CLF. Not singling
> > out anyone in particular but the bitch-fests that I've seen on this
> > group far outweigh the actual useful posts where people actually try
> > to help one-another.
> >
> > Just an observation...
> 
> I hope you aren't referring to my posts.  I try to avoid confrontation, 
> but know I push Hugh's buttons sometimes.  I also get into "discussions" 
> with Bernd sometimes that are less than productive.  I was surprised 
> that a recent interaction with Hugh started to go in a semi-useful 
> direction for a moment.  If I am crossing lines I would like for someone 
> to tell me, but I expect it is hard to know where the line is in this 
> group.  At least it isn't s.e.d where anything goes, including 
> references to Nazis, lol.
> -- 

Posted about this earlier. Just feel this group needs to be less egotistic and more welcoming. Most of the discussions gravitate towards shouting matches.

-Yvo

[toc] | [prev] | [next] | [standalone]

#41729

On 9/4/2015 12:20 PM, Mux wrote:
>> Is your memory external?  I've never gone that route since my uses
>> for internal CPUs are always 100% internal.  I typically don't have
>> room on the board for an external memory or the design is a
>> retrofit where there was none in the first place.  Prefetching
>> doesn't speed up a CPU running from internal memory since the block
>> RAM is nearly as fast as a register.
>>
> Memory is external. 64kx16 static ram at 10ns which allows me to do
> pre-fetching if the last instruction isn't referencing memory. Check
> out Eric La-Forests paper for more info.
>
>> BTW, what are your 4 bit instructions?  I've never been able to
>> convince myself such a small instruction is the way to go.  Just as
>> stack ISAs generate a fair percentage of code to thrash the stack,
>> small instructions exacerbate this with the very few instructions
>> possible.
>
> Yup. It's taking MISC to an absolute level but it kinda works. See if
> I can remember...
> PC@,LIT,+,AND,XOR,2/,0=,DUP,DROP,OVER,PUSH,POP,@,!,JUMP,CALL.
>
> From Eric's paper, PC@ is an instruction that literally fetches the
> next 4 instructions. While that does mean an extra clock per every 4
> instructions, most of the time the prefetcher manages to avoid it.
> Given that you generally need more stack operations, this increases
> the frequency the prefetcher is able to kick in. As Eric mentioned,
> it's a really elegant solution as it gets automatically shifted in
> (all zeroes) and thus becomes the '5th' instruction, which is why
> it's coded as 0. Ting's 4-bit CPU and others use a 2-bit instruction
> counter and a nop, which means you have to NOP out your IR and stall
> rather than early-out.
>
> The interrupt mechanism, which happens when a PC@ is about to
> execute, is basically a mux that either gates { DUP,DUP,XOR,CALL } or
> the next instruction word from memory and calls address 0, which has
> code that determines how it got there (i.e. interrupt bit set ->
> interrupt ).
>
> Jump is conditional and works closely with 0= to mask off addresses.
> A side effect is that you can never jump to zero, which is fine. Exit
> is encoded as { pop, jump }.
>
> Call on the other hand IS able to jump to zero and therefore allows
> me to generate a call without referencing memory and hardwiring
> reset/irq to the same address.
>
> One last thing is that LIT is the only instruction that references
> memory. So jump / call first put the address on the datastack. Mainly
> did this to simplify stuff.
>
> 4-bits is really pushing it but it was an interesting exercise /
> experiment to see what you can do. Code density is reasonably high in
> places but, as you stated already, you end up with more instructions
> to do the same. To that extent, I'm currently working on a new 5-bit
> CPU :-)
>
> Btw, if anyone's interested I can post my verilog code on OpenCores.
>
>> I'm wondering if VLIW isn't the way to go for stack machines.  But
>> then the tools get more complex to optimize the parallelism or the
>> user has to figure it all out themselves.
>>
>
> Thing with VLIW is that you have a lot of unused units sitting idle
> that takes up space. I remember working on VMLabs' Nuon which had a
> theoretical '28 instructions per clock' spread out over 4 cores. Died
> a horrible death but was a pretty neat architecture at the time.

I'm not sure why that would be.  Perhaps I am not familiar with some of 
the VLIW architectures, but to me it allows maximum parallelism.  I 
worked on an array processor which had four ALUs (two add/sub and two 
mul plus a div/sq root which was multicycle so tthey didn't count it in 
the four) and a storage move processor (SMP, very fancy DMA) all 
controlled by 100+ bit control words.   They called it "microcode" but 
was the assembly language for this machine and the only way to program 
it.  These days it would be called a VLIW machine, no?  The point was to 
have total control over all the operations of the machine to get maximum 
parallelism with no restrictions.  There were no idle units unless you 
just plain had no use for them and every CPU has that all the time.


> Posted about this earlier. Just feel this group needs to be less
> egotistic and more welcoming. Most of the discussions gravitate
> towards shouting matches.

I WELCOME YOUR IDEAS!  ;)

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#41730

> I'm not sure why that would be.  Perhaps I am not familiar with some of 
> the VLIW architectures, but to me it allows maximum parallelism.  I 
> worked on an array processor which had four ALUs (two add/sub and two 
> mul plus a div/sq root which was multicycle so tthey didn't count it in 
> the four) and a storage move processor (SMP, very fancy DMA) all 
> controlled by 100+ bit control words.   They called it "microcode" but 
> was the assembly language for this machine and the only way to program 
> it.  These days it would be called a VLIW machine, no?  The point was to 
> have total control over all the operations of the machine to get maximum 
> parallelism with no restrictions.  There were no idle units unless you 
> just plain had no use for them and every CPU has that all the time.
> 
Yeah, that's VLIW alright. The Nuon had 4 CPU's and relied heavily on DMA as they only had tiny caches (3 CPU's had 4K and 1 of them only had 8k) with external SDRAM for filling them. Each VLIW word was 128bits wide and could process 7 instructions in parallel which, times 4 gives you a theoretical 28 instructions / clock :-)

Anyway, you can read more about it here:

http://cdn.arstechnica.net/wp-content/uploads/2015/06/1383659488_NUON-Architecture-26-OEM.pdf

> I WELCOME YOUR IDEAS!  ;)
> 

Great! I'm all for healthy discussions and what not as long as they're constructive :-)

[toc] | [prev] | [next] | [standalone]

#41672

rickman wrote:
> You get hung up in meaningless distinctions while missing the point.
> "Bit lines" *are* multiplexors using a wire OR.

No, a multiplexer is a logic gate.  RAM is deliberately minimized special-
purpose circuitry, even with dynamic elements (the bit line is precharged, 
so it doesn't have a pullup like a wired or, and it's used for both 
directions, reading and writing; you have to be careful with your design 
that writing actually flips a bit - it's at the border between analog and 
digital design).

> You DO see dual port RAMs in FPGAs.... in fact it is hard to find RAMs
> that AREN'T dual port.

I did in fact write that.

> By using two such RAMs in parallel you can have
> three ports implementing 2 reads and 1 write in any clock cycle.  I have
> done this.

Sounds like a stupid idea.  By using some flip-flops for TOS (16 for 16 
bits), you can use an entire RAM block for something else.  And you reduce 
your cycle time, because the read/write time to the TOS element in RAM is no 
longer in the critical path.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#41676

On 9/2/2015 5:35 PM, Bernd Paysan wrote:
> rickman wrote:
>> You get hung up in meaningless distinctions while missing the point.
>> "Bit lines" *are* multiplexors using a wire OR.
>
> No, a multiplexer is a logic gate.  RAM is deliberately minimized special-
> purpose circuitry, even with dynamic elements (the bit line is precharged,
> so it doesn't have a pullup like a wired or, and it's used for both
> directions, reading and writing; you have to be careful with your design
> that writing actually flips a bit - it's at the border between analog and
> digital design).

I'm not going to argue such a silly topic.  I don't care how you 
implement a multiplexor, it is still a mux.


>> You DO see dual port RAMs in FPGAs.... in fact it is hard to find RAMs
>> that AREN'T dual port.
>
> I did in fact write that.
>
>> By using two such RAMs in parallel you can have
>> three ports implementing 2 reads and 1 write in any clock cycle.  I have
>> done this.
>
> Sounds like a stupid idea.  By using some flip-flops for TOS (16 for 16
> bits), you can use an entire RAM block for something else.  And you reduce
> your cycle time, because the read/write time to the TOS element in RAM is no
> longer in the critical path.

Ok, so you acknowledge that you can do all the operations for an ADD out 
of RAM at the same time and that you can have more than 2 port RAM in an 
FPGA?

You may think it a stupid idea, but "stupid is as stupid does". 
Different requirements for different projects.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#41681

rickman wrote:
> I'm not going to argue such a silly topic.  I don't care how you
> implement a multiplexor, it is still a mux.

You are just clueless, and at the same time you want to be right.  Have you 
graduated from kindergarden yet?

Your description of what a RAM is was simply very naive and inaccurate.  
Neither is an SRAM cell a register, nor is a bitline a multiplexer, because 
functionally, it does only part of the job, and both multiplexing and 
demultiplexing (for write, you need a demultiplexer).  The other parts of 
the job are done by the word line and the sense amplifiers+precharge 
drivers.  And if you want to have the edge-triggered RAM block (as you get 
in the FPGA case), you need registers to store the inputs.  That's all 
"hidden" from your naive view in the block RAM macro.

As FPGA-only developer, you probably think you don't need to know what it 
is.

> Ok, so you acknowledge that you can do all the operations for an ADD out
> of RAM at the same time and that you can have more than 2 port RAM in an
> FPGA?

You need to use two RAM blocks to get more than 2 ports...  Using two RAM 
blocks for what can be done with one is a waste of resources.  Having to 
jump through the hoops of connecting two RAM blocks just to get one port 
more is a waste of programming time.

> You may think it a stupid idea, but "stupid is as stupid does".
> Different requirements for different projects.

What's you requirement that drives you to use two block RAMs where one would 
be sufficient?  You always can do things with more resources, slower.  
Requirements usually press you towards doing things with less resources, 
faster.  Unless you don't have any requirements, then you can waste 
resources as much as you like.

IMHO, wasting resources by itself is stupid.

The code doesn't become more complicated with a TOS in registers, either.  
It's not a premature optimization, it's something that goes without 
thinking.  We have cached the top of stack in many software Forth 
implementations for ages, and it not only makes the Forth faster, but the 
code easier to write.

It's probably like using a big block 400 cubic inch V8 motor to go 65mhp.  
You can do that with the 600cm³ (less than 40 cubic inches) two-cylinder 
motor of a 2CV.

As a Forth programmer, I hate bloat just for the sake of bloat.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#41684

On 9/2/2015 8:07 PM, Bernd Paysan wrote:
> rickman wrote:
>> I'm not going to argue such a silly topic.  I don't care how you
>> implement a multiplexor, it is still a mux.
>
> You are just clueless, and at the same time you want to be right.  Have you
> graduated from kindergarden yet?

Whatever...  I'm not interested in splitting hairs on this.  The point 
is you said, "Can't be done in RAM." because you have a preconceived 
idea of what a RAM is.  It can be, and *is* done with RAM.


> What's you requirement that drives you to use two block RAMs where one would
> be sufficient?

How about a design that is out of logic and has free ram blocks?  Or one 
that needs a larger register file than is practical in distributed logic?


> It's probably like using a big block 400 cubic inch V8 motor to go 65mhp.
> You can do that with the 600cm³ (less than 40 cubic inches) two-cylinder
> motor of a 2CV.

Not if you are towing a 5000 lb boat.

Why are we even discussing this?  I feel this is a waste of bandwidth. 
We both have more useful things to do... I'm going to do them.  :)

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#41694

rickman wrote:

> On 9/2/2015 8:07 PM, Bernd Paysan wrote:
>> rickman wrote:
>>> I'm not going to argue such a silly topic.  I don't care how you
>>> implement a multiplexor, it is still a mux.
>>
>> You are just clueless, and at the same time you want to be right.  Have
>> you graduated from kindergarden yet?
> 
> Whatever...  I'm not interested in splitting hairs on this.  The point
> is you said, "Can't be done in RAM." because you have a preconceived
> idea of what a RAM is.  It can be, and *is* done with RAM.

I've the idea of a real RAM, because I know what a real RAM is.  Can't be 
done with one block RAM.  Can be done with two, yes, but that's a waste of 
resources.

>> What's you requirement that drives you to use two block RAMs where one
>> would be sufficient?
> 
> How about a design that is out of logic and has free ram blocks?  Or one
> that needs a larger register file than is practical in distributed logic?

The logic to access the two RAMs costs more LEs than putting TOS into 
registers.

If you want to implement a 3-register RISC architecture, your approach is 
the only way to go.  But you don't, you implement a stack CPU.

>> It's probably like using a big block 400 cubic inch V8 motor to go 65mhp.
>> You can do that with the 600cm³ (less than 40 cubic inches) two-cylinder
>> motor of a 2CV.
> 
> Not if you are towing a 5000 lb boat.

The thing you do is actually slower...

> Why are we even discussing this?  I feel this is a waste of bandwidth.
> We both have more useful things to do... I'm going to do them.  :)

Probably.  Your design approach just makes me cringe.  I think you really 
can learn something here.  But I think you don't want to.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#41671

On Sunday, August 30, 2015 at 7:01:59 PM UTC-7, pbj...@gmail.com wrote:
> Seeing that the Parallax Propeller forums are down at the moment I know that my Tachyon Forth implemented on the 8 core 32-bit Propeller works well without "interrupts" ...
> 
> In fact cores are so much better than interrupts as they can be dedicated to the task at hand without distraction. For instance I am developing a 32 channel serial asynch with any mix of rx and tx (32 total) that is designed to work at 115,200 baud although the transmitters are quite happy working even at 1M baud, all in one core without any dedicated hardware UARTs etc. I've only spent less than a day on this and already the transmitter section is working very well without any jitter etc and now I am down to testing the receiver section while I get sidetracked and program one of the cores as a resident logic analyser. 
> wOOt!

Every time that somebody writes a Forth program that works, this is another nail in the coffin of Forth-200x --- I'm assuming here that any Forth program that works, will necessarily be written in a non-standard Forth (because Standard Forth is a bug-ridden mess designed by an idiot sales-person).

ANS-Forth was just a marketing gimmick from Elizabeth Rather intended to fool the world into believing that Forth Inc. sets the standard for the industry and that all Forth programmers are dependent upon Forth Inc. for leadership --- Forth-200x is just more of the same, as it is mandated to be 100% compatible with ANS-Forth --- the Forth-200x committee relies entirely upon every Forth programmer being a failure at programming, and there is nothing that they hate and fear more than a Forth programmer who is capable of writing programs that work.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.forth

csiph-web