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 1 of 3  [1] 2 3  Next page →

#41540 — Forth CPUs with NO Interrupts

The register thread made me realize that one of the greatest 
accomplishments of the GA144 is not any of the typically quoted features 
of the inter-processor communications or the small CPU size.  It is the 
fact that programming the processor is made so much simpler by not 
having *interrupts*.  Interrupts make the design of any processor 
significantly more complex, not to mention the software.

I think there was a discussion in one of the FPGA groups where a stack 
CPU design was criticized for not including a semaphore instruction 
which allowed inter-process communications to be implemented without 
tons of work.  The "forth" solution would be to just not allow 
interrupts and to not have multiprocessing!

I still see the GA144 as a sort of FPGA that supports software on each 
of the logic blocks.  This may be one of those things that is just a bit 
ahead of its time.  When technology reaches a point where a GA256K is 
available, maybe we will know how to properly utilize vast arrays of 
processors.  While there are many flaws in the GA144 system level 
design, I think much of the criticism leveled toward it is due to 
potential users viewing it through conventional CPU glasses.

-- 

Rick

[toc] | [next] | [standalone]

#41547

rickman <gnuarm@gmail.com> writes:
>I think there was a discussion in one of the FPGA groups where a stack 
>CPU design was criticized for not including a semaphore instruction 
>which allowed inter-process communications to be implemented without 
>tons of work.  The "forth" solution would be to just not allow 
>interrupts and to not have multiprocessing!

The classical Forth solution is to have cooperative round-robin
multi-tasking, and there you know where the task switches can happen
(at PAUSE and I/O words), and everything that does not contain such
words is executed atomically (apart from interrupts); semaphores, if
necessary, can be built out of simpler words.  Interrupts were
supported, but typically just acticated a task that did the actual
work when the round-robin scheduler came to it.

If course, this simplicity is no longer possible with we want multiple
cores to work.  You can look at Chuck Moore's recent work to see his
solution for the resulting problems: No shared memory, communication
and synchronization through links with almost no buffering.  Not sure
if that's enough in general, though.  Anyway, other processors don't
have semaphore instructions, either, they have stuff from which
semaphores and other synchronization primitives can be built.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#41556

On 8/26/2015 4:51 AM, Anton Ertl wrote:
> rickman <gnuarm@gmail.com> writes:
>> I think there was a discussion in one of the FPGA groups where a stack
>> CPU design was criticized for not including a semaphore instruction
>> which allowed inter-process communications to be implemented without
>> tons of work.  The "forth" solution would be to just not allow
>> interrupts and to not have multiprocessing!
>
> The classical Forth solution is to have cooperative round-robin
> multi-tasking, and there you know where the task switches can happen
> (at PAUSE and I/O words), and everything that does not contain such
> words is executed atomically (apart from interrupts); semaphores, if
> necessary, can be built out of simpler words.  Interrupts were
> supported, but typically just acticated a task that did the actual
> work when the round-robin scheduler came to it.
>
> If course, this simplicity is no longer possible with we want multiple
> cores to work.  You can look at Chuck Moore's recent work to see his
> solution for the resulting problems: No shared memory, communication
> and synchronization through links with almost no buffering.  Not sure
> if that's enough in general, though.  Anyway, other processors don't
> have semaphore instructions, either, they have stuff from which
> semaphores and other synchronization primitives can be built.

I don't recall the particulars, but the guy complaining about this CPU 
design was saying you can't construct a useful semaphore without a *lot* 
of headache unless you design an atomic test-modify-write instruction or 
similar.  I supposed you can disable interrupts while you do this in 
multiple instructions, but I think he was saying this becomes unwieldy 
and greatly increases the interrupt response time as well as the 
response jitter.

His rant seemed to be that it is not practical to give such CPUs an OS.

-- 

Rick

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

#41564

On 8/25/15 10:51 PM, Anton Ertl wrote:
> rickman <gnuarm@gmail.com> writes:
>> I think there was a discussion in one of the FPGA groups where a stack
>> CPU design was criticized for not including a semaphore instruction
>> which allowed inter-process communications to be implemented without
>> tons of work.  The "forth" solution would be to just not allow
>> interrupts and to not have multiprocessing!
>
> The classical Forth solution is to have cooperative round-robin
> multi-tasking, and there you know where the task switches can happen
> (at PAUSE and I/O words), and everything that does not contain such
> words is executed atomically (apart from interrupts); semaphores, if
> necessary, can be built out of simpler words.  Interrupts were
> supported, but typically just acticated a task that did the actual
> work when the round-robin scheduler came to it.
>
> If course, this simplicity is no longer possible with we want multiple
> cores to work.  You can look at Chuck Moore's recent work to see his
> solution for the resulting problems: No shared memory, communication
> and synchronization through links with almost no buffering.  Not sure
> if that's enough in general, though.  Anyway, other processors don't
> have semaphore instructions, either, they have stuff from which
> semaphores and other synchronization primitives can be built.

GA's concept is that the multiple cores are tiny and numerous, and in 
effect replace the need for any multitasking within a core.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#41553

On Wednesday, 26 August 2015 05:53:18 UTC+1, rickman  wrote:
> The register thread made me realize that one of the greatest 
> accomplishments of the GA144 is not any of the typically quoted features 
> of the inter-processor communications or the small CPU size.  It is the 
> fact that programming the processor is made so much simpler by not 
> having *interrupts*.  Interrupts make the design of any processor 
> significantly more complex, not to mention the software.

I can imagine that interrupts do indeed make the hardware side
more complex. Regarding the software side, you might be interested
in the approach taken by Texas Instruments in the 1970s with their
990/x line of mini computers.

The 9900/x mini's had a CPU that was originally built from discrete
logic, like most of the minis back then (PDPs etc) on plug in boards.
Later on it was integrated into a single chip in the form of the
TMS9900 and decscendants.

The TMS9900 has a unique architecture: It has 16 general purpose
registers, but, uniquely, the registers do not reside on the chip.
The registers are in regular RAM, and can be anywhere. The CPU
only has three on-board registers: PC (program counter), ST (status
register) and WP (workspace pointer).

Using the LWPI instruction, (Load Workspace Pointer) you can have
as many sets of 16 registers as you have memory for. They can even
overlap if that's what you want to do. Certain instructions, for
example BLWP (branch and load workspace pointer) allow you to 
specify an address to branch to, and critically, an address from
which the 16 registers will be taken from in RAM. Thusly, 
subroutines can each have their own set of registers - meaning the
registers effectively become local variables.

Interrupts on the 9900 are programmed using vectors. Some locations
in memory are reserved for vectors. So, when a level 4 interrupt
(for example) comes in, the processor reads the level 4 vector.
In that vector are two pointers: The address of an interrupt
service routine, and the address of the registers for that ISR.
Thusly, interrupts are very fast indeed - no registers need to
be pushed to stacks in order to save their contents - the ISR
(every ISR) can have its own register workspace. Same for subroutines.

Even better, when an interrupt occurs, or a subroutine is called
using BLWP, three registers in the *new* workspace are loaded with:

Previous contents of program counter (for returning from ISR or SR)
Previous contents of status register
Previous address of register set

So, having serviced your interrupt, or finished your subroutine,
you can return, seamlessly, back to your main program. The entire
previous context of the machine is restored instantly. The contents
of the registers stay where they were: in RAM.
Using this technique, routines can call routines, that call routines
that call routines, each having their own register set, and if
an interrupt arrives while it's all happening, the programmer makes
precisely no effort at all. Just let it happen. It'll all unwind
itself.

It's a brilliant architecture (in practice, the implementation 
used in the 9900 could be better, it was massively improved in
the TMS9995) that actually makes the silicon a lot simpler.
Move the registers off the chip into memory. You won't get 
the fastest performance using that technique (you have to go
out on the address and data busses (obviously) to fetch your 
registers), but you can get a nice simple design and programming
it is like falling off a log!

Mark

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

#41555

On 8/26/2015 7:33 AM, Mark Wills wrote:
> On Wednesday, 26 August 2015 05:53:18 UTC+1, rickman  wrote:
>> The register thread made me realize that one of the greatest
>> accomplishments of the GA144 is not any of the typically quoted features
>> of the inter-processor communications or the small CPU size.  It is the
>> fact that programming the processor is made so much simpler by not
>> having *interrupts*.  Interrupts make the design of any processor
>> significantly more complex, not to mention the software.
>
> I can imagine that interrupts do indeed make the hardware side
> more complex. Regarding the software side, you might be interested
> in the approach taken by Texas Instruments in the 1970s with their
> 990/x line of mini computers.
>
> The 9900/x mini's had a CPU that was originally built from discrete
> logic, like most of the minis back then (PDPs etc) on plug in boards.
> Later on it was integrated into a single chip in the form of the
> TMS9900 and decscendants.
>
> The TMS9900 has a unique architecture: It has 16 general purpose
> registers, but, uniquely, the registers do not reside on the chip.
> The registers are in regular RAM, and can be anywhere. The CPU
> only has three on-board registers: PC (program counter), ST (status
> register) and WP (workspace pointer).
>
> Using the LWPI instruction, (Load Workspace Pointer) you can have
> as many sets of 16 registers as you have memory for. They can even
> overlap if that's what you want to do. Certain instructions, for
> example BLWP (branch and load workspace pointer) allow you to
> specify an address to branch to, and critically, an address from
> which the 16 registers will be taken from in RAM. Thusly,
> subroutines can each have their own set of registers - meaning the
> registers effectively become local variables.
>
> Interrupts on the 9900 are programmed using vectors. Some locations
> in memory are reserved for vectors. So, when a level 4 interrupt
> (for example) comes in, the processor reads the level 4 vector.
> In that vector are two pointers: The address of an interrupt
> service routine, and the address of the registers for that ISR.
> Thusly, interrupts are very fast indeed - no registers need to
> be pushed to stacks in order to save their contents - the ISR
> (every ISR) can have its own register workspace. Same for subroutines.
>
> Even better, when an interrupt occurs, or a subroutine is called
> using BLWP, three registers in the *new* workspace are loaded with:
>
> Previous contents of program counter (for returning from ISR or SR)
> Previous contents of status register
> Previous address of register set
>
> So, having serviced your interrupt, or finished your subroutine,
> you can return, seamlessly, back to your main program. The entire
> previous context of the machine is restored instantly. The contents
> of the registers stay where they were: in RAM.
> Using this technique, routines can call routines, that call routines
> that call routines, each having their own register set, and if
> an interrupt arrives while it's all happening, the programmer makes
> precisely no effort at all. Just let it happen. It'll all unwind
> itself.
>
> It's a brilliant architecture (in practice, the implementation
> used in the 9900 could be better, it was massively improved in
> the TMS9995) that actually makes the silicon a lot simpler.
> Move the registers off the chip into memory. You won't get
> the fastest performance using that technique (you have to go
> out on the address and data busses (obviously) to fetch your
> registers), but you can get a nice simple design and programming
> it is like falling off a log!

I still have a TMS9995 CPU card I built many years ago.  I remember that 
I got it to work, but never made it do anything useful.  I think I was 
going to connect it to an LCD from a UPS truck.  Not sure why I didn't, 
I think it had to do with getting my hands on a Heathkit LSI-11 which 
made the TMS devices fade into the background, lol.

-- 

Rick

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

#41566

On Wednesday, August 26, 2015 at 1:33:44 PM UTC+2, Mark Wills wrote:

Thanks a lot for this very clear explanation! 

It reads very much like the transputer architecture (although
the 'puter additionally had hardware floating-point AND shallow 
stacks). 

-marcel

PS: Why not have 16 extra cores, with limited functionality,
for interrupts? They would only need specific instructions,
and maybe it would be OK if they could only address say 
1K of windowable memory. They could even be revamped 9900s :-)

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

#41567

On Wednesday, August 26, 2015 at 4:33:44 AM UTC-7, Mark Wills wrote:
> On Wednesday, 26 August 2015 05:53:18 UTC+1, rickman  wrote:
> > The register thread made me realize that one of the greatest 
> > accomplishments of the GA144 is not any of the typically quoted features 
> > of the inter-processor communications or the small CPU size.  It is the 
> > fact that programming the processor is made so much simpler by not 
> > having *interrupts*.  Interrupts make the design of any processor 
> > significantly more complex, not to mention the software.
> 
> I can imagine that interrupts do indeed make the hardware side
> more complex. Regarding the software side, you might be interested
> in the approach taken by Texas Instruments in the 1970s with their
> 990/x line of mini computers.
> 
> The 9900/x mini's had a CPU that was originally built from discrete
> logic, like most of the minis back then (PDPs etc) on plug in boards.
> Later on it was integrated into a single chip in the form of the
> TMS9900 and decscendants.
> 
> The TMS9900 has a unique architecture: It has 16 general purpose
> registers, but, uniquely, the registers do not reside on the chip.
> The registers are in regular RAM, and can be anywhere. The CPU
> only has three on-board registers: PC (program counter), ST (status
> register) and WP (workspace pointer).
> 
> Using the LWPI instruction, (Load Workspace Pointer) you can have
> as many sets of 16 registers as you have memory for. They can even
> overlap if that's what you want to do. Certain instructions, for
> example BLWP (branch and load workspace pointer) allow you to 
> specify an address to branch to, and critically, an address from
> which the 16 registers will be taken from in RAM. Thusly, 
> subroutines can each have their own set of registers - meaning the
> registers effectively become local variables.
> 
> Interrupts on the 9900 are programmed using vectors. Some locations
> in memory are reserved for vectors. So, when a level 4 interrupt
> (for example) comes in, the processor reads the level 4 vector.
> In that vector are two pointers: The address of an interrupt
> service routine, and the address of the registers for that ISR.
> Thusly, interrupts are very fast indeed - no registers need to
> be pushed to stacks in order to save their contents - the ISR
> (every ISR) can have its own register workspace. Same for subroutines.
> 
> Even better, when an interrupt occurs, or a subroutine is called
> using BLWP, three registers in the *new* workspace are loaded with:
> 
> Previous contents of program counter (for returning from ISR or SR)
> Previous contents of status register
> Previous address of register set
> 
> So, having serviced your interrupt, or finished your subroutine,
> you can return, seamlessly, back to your main program. The entire
> previous context of the machine is restored instantly. The contents
> of the registers stay where they were: in RAM.
> Using this technique, routines can call routines, that call routines
> that call routines, each having their own register set, and if
> an interrupt arrives while it's all happening, the programmer makes
> precisely no effort at all. Just let it happen. It'll all unwind
> itself.
> 
> It's a brilliant architecture (in practice, the implementation 
> used in the 9900 could be better, it was massively improved in
> the TMS9995) that actually makes the silicon a lot simpler.
> Move the registers off the chip into memory. You won't get 
> the fastest performance using that technique (you have to go
> out on the address and data busses (obviously) to fetch your 
> registers), but you can get a nice simple design and programming
> it is like falling off a log!
> 
> Mark

The TI9900 is pretty cool --- way ahead of its time --- similar to the Sun Sparc with that movable set of pseudo-registers.

In regard to interrupts, the MiniForth didn't have them --- it polled I/O as part of NEXT and would call an ISR if needed --- the primitives were generally short and fast because they didn't do any branching internally, so I/O didn't get lost (multiplication and division had to be factored though, as those were too slow otherwise).

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

#41570

On 8/26/2015 3:50 PM, hughaguilar96@gmail.com wrote:
>
> The TI9900 is pretty cool --- way ahead of its time --- similar to
> the Sun Sparc with that movable set of pseudo-registers.
>
> In regard to interrupts, the MiniForth didn't have them --- it polled
> I/O as part of NEXT and would call an ISR if needed --- the
> primitives were generally short and fast because they didn't do any
> branching internally, so I/O didn't get lost (multiplication and
> division had to be factored though, as those were too slow
> otherwise).

That sounds like Miniforth *did* have interrupts.  I can't imagine it 
would be polling I/O in the NEXT routine using Forth instructions, that 
would be an enormous overhead.  More likely hardware monitored 
interrupts and when NEXT happened the interrupts were enabled.

Did this thing really have a NEXT routine?  That alone sounds 
inefficient.  Next is basically the fetching and execution of the next 
Forth instruction which really should be done in hardware just as any 
CPU would do.

-- 

Rick

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

#41588

On Wednesday, August 26, 2015 at 4:33:44 AM UTC-7, Mark Wills wrote:
> I can imagine that interrupts do indeed make the hardware side
> more complex. 

The point I was making in regard to the MiniForth, is that you don't need to have interrupts that can occur after ANY machine-instruction anywhere. You can just have one machine-instruction that can interrupt itself if an interrupt is necessary --- so all the complexity is buried in that one machine-instruction. In the MiniForth that instruction was NEXT because it gets executed very frequently. Also, the general-purpose registers (such as the carry bit) never carry data from one primitive to the next, but are only used internally within each primitive, so they don't have to be saved and restored because they are guaranteed to be invalid at the time that NEXT executes.

I don't know anything about HDL, so I can't really comment on how much complexity was reduced with this method --- I had no involvement in writing the HDL code for the MiniForth (or in writing the HDL itself, which was done before I even started work there).

I wrote the assembler/simulator. I remember that up to five instructions could be packed into a single opcode, and all of them would execute concurrently (each opcode took one clock cycle). The job of the assembler was to rearrange the instructions so as to pack as many into each opcode as possible (minimize how many slots got filled with a NOP), while yet guaranteeing that the generated code did the same thing as it would if one instruction were in each opcode and the instructions were in the same order as they had been in the source-code. It was all about knowing which registers each instruction depended upon and which registers it affected, and making sure that no instruction that needed certain registers got compiled ahead of the instruction that set those registers --- this was similar to the "out of order execution" of the x86 processors, except that I was doing it at compile-time rather than run-time. The NEXT instruction always parallelized with (got packed together with) other instructions so it took zero clock cycles (the only exception was the NOOP primitive, because there weren't any other instruction to parallelize NEXT with). NEXT accessed memory, so it couldn't be packed together with any other instruction that accessed memory, but there were always instructions nearby that just accessed registers and NEXT would get packed in with them. The MiniForth was Harvard Architecture, so by "memory" I mean the data memory (both data and Forth code) --- there was a separate memory for the machine-code.

> Interrupts on the 9900 are programmed using vectors. Some locations
> in memory are reserved for vectors. So, when a level 4 interrupt
> (for example) comes in, the processor reads the level 4 vector.
> In that vector are two pointers: The address of an interrupt
> service routine, and the address of the registers for that ISR.
> Thusly, interrupts are very fast indeed - no registers need to
> be pushed to stacks in order to save their contents - the ISR
> (every ISR) can have its own register workspace. Same for subroutines.
> 
> Even better, when an interrupt occurs, or a subroutine is called
> using BLWP, three registers in the *new* workspace are loaded with:
> 
> Previous contents of program counter (for returning from ISR or SR)
> Previous contents of status register
> Previous address of register set
> 
> So, having serviced your interrupt, or finished your subroutine,
> you can return, seamlessly, back to your main program. The entire
> previous context of the machine is restored instantly. The contents
> of the registers stay where they were: in RAM.
> Using this technique, routines can call routines, that call routines
> that call routines, each having their own register set, and if
> an interrupt arrives while it's all happening, the programmer makes
> precisely no effort at all. Just let it happen. It'll all unwind
> itself.

The MiniForth had sixteen 16-bit pseudo-registers that were in memory. They were at a fixed location (address zero) however, so they couldn't be relocated like in your TI9900. Having a base pointer for the registers is actually a pretty cool idea though --- we should have done that in the MiniForth.

Actually, the pseudo-registers weren't even added to the MiniForth design until the very end of the project. This was after the entire motion-control program had been written. The pseudo-registers were added because the next project was a C compiler and I said that I needed pseudo-registers because LCC (I was planning on retargeting LCC to generate code for the MiniForth) expected to have a set of registers available. The C compiler project died though, mostly because I didn't know very much about LCC and Testra wasn't willing to pay me to learn --- they expected me to already be an expert in LCC, similar to how I was already an expert in UR/Forth when I started working there --- I can't be an expert in everything though, and I'm not going to spend my free time learning something that I have no interest in outside of my job. Also, I was quite dubious that the MiniForth would be competitive running C programs against mainstream processors (such as the MC6812) that were designed specifically to support C --- the MiniForth could blow away mainstream processors (such as the MC6812) in running Forth programs --- everybody wants to program in C rather than in Forth though, so there was no interest in the MiniForth processor anywhere (afaik, the motion-control boards are the only application that it has ever been used for).

MFX would have been a lot different if I had known at the beginning that pseudo-registers were going to be included in the design. All I was told at the beginning was that the goal was to port the motion-control program over from 80c320 UR/Forth to the MiniForth --- UR/Forth expected a basic stack-machine (it didn't have local variables), so the MiniForth was a basic stack-machine (only after I got the pseudo-registers did I add local variables, but they weren't used in the motion-control program that was already written).

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

#41601

It's not that much that it's more difficult from an HDL perspective but rather the CPU you're implementing. The more complicated your architecture, the more overhead you'll have to implement it.

Most stack computers have no condition flags to save, so all it really becomes is saving the next PC and CALLing the the ISR. Most register CPU's have a lot more to do but a lot of that is still left up to the programmer and the bare minimum is performed. Of course, with Superscalar and OoO operations, you'll need to flush the entire pipeline and what not, which will take a LOT of cycles. At a minimum, something like a 6502 pushes the status register and the next PC before calling the ISR. A special RTI (return from interrupt) differs from an RTS in that it does the extra pull.

For an interpreted software forth implementation, I don't see anything wrong polling at next. In fact, I'm pretty sure that's what microcode machines do as well :-)

As I alluded to earlier, my C4 core checks for interrupts once the ISR is empty and then, rather than loading the next set of instructions from the PC, replaces it with an ISR call.

-Y

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

#41560

On 26/08/2015 12:53 AM, rickman wrote:
> The register thread made me realize that one of the greatest
> accomplishments of the GA144 is not any of the typically quoted
> features of the inter-processor communications or the small CPU size.
> It is the fact that programming the processor is made so much simpler
> by not having *interrupts*.  Interrupts make the design of any
> processor significantly more complex, not to mention the software.
>

Interrupt context switching has always been a software nightmare. There
have been many approaches from hardware saving registers or not. No
matter what the approach it is always a comes down to one of two metrics
minimum switch speed vs minimum execution cycles.

In one processor design project we chose that all interrupts would be
run to completion so that interrupts could only happen at the pleasure
of the application developer. This minimizes the amount of context
needed and minimizes the average cycle count. We compensated for switch
delays by being able to precomputed event driven I/O transfers in hardware.


w..

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

#41561

On 26/08/2015 05:53, rickman wrote:
> The register thread made me realize that one of the greatest
> accomplishments of the GA144 is not any of the typically quoted features
> of the inter-processor communications or the small CPU size.  It is the
> fact that programming the processor is made so much simpler by not
> having *interrupts*.  Interrupts make the design of any processor
> significantly more complex, not to mention the software.
>
<snip>

For me, one of the attractions of a stack machine is that interrupts can 
be very low latency - there's nothing to stack, it's already there. 
(Ok, probably need to stack a mode register or two.)

But I take the point - one or more simpler processors per task is good.

Cheers
-- 
Syd

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

#41563

That's kinda why I brought up the part about registers. In a 'pure' stack machine architecture an interrupt does indeed become just a call. As long as it doesn't allow for re-entrant interrupts and leaves the state of the stack where it was before the entry point, it's literally just a single subroutine call with the caveat that when you use encoded (i.e. 5:5:5) instructions, you can only service the interrupt when your instruction register has been fully emptied.

My 'C4' forth core, which only has 16 instructions basically deals with interrupts by loading the IR with 'dup dup xor call' instead of the next instruction word from memory, which effectively executes a subroutine call to address zero. Since reset *also* starts at address zero, there's a check to see how it got there, either from a fresh reset (interrupt request is cleared on reset) or by interrupt, in which case the interrupt request bit is set.

While it's a simple solution with minimal overhead, NOT having interrupts and having multiple cores makes things more interesting and also does away with the whole register state stuff.

-Y

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

#41571

On 8/26/2015 12:12 PM, Syd Rumpo wrote:
> On 26/08/2015 05:53, rickman wrote:
>> The register thread made me realize that one of the greatest
>> accomplishments of the GA144 is not any of the typically quoted features
>> of the inter-processor communications or the small CPU size.  It is the
>> fact that programming the processor is made so much simpler by not
>> having *interrupts*.  Interrupts make the design of any processor
>> significantly more complex, not to mention the software.
>>
> <snip>
>
> For me, one of the attractions of a stack machine is that interrupts can
> be very low latency - there's nothing to stack, it's already there. (Ok,
> probably need to stack a mode register or two.)
>
> But I take the point - one or more simpler processors per task is good.

You only have nothing to stack if you have no data that needs to be 
preserved between invocations.  I think most interrupt processes have 
data that needs to be preserved.

-- 

Rick

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

#41578

Not forth CPU, but it does not have interrupts IIRC, P8X32A from basic stamp creator Parallax

https://www.parallax.com/sites/default/files/downloads/P8X32A-Propeller-Datasheet-v1.4.0_0.pdf

with an 8 cores, and somewhat interesting design to look at.

Ala'a

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

#41619

On Wednesday, August 26, 2015 at 2:53:18 PM UTC+10, rickman wrote:
<snip>
> It is the 
> fact that programming the processor is made so much simpler by not 
> having *interrupts*.  Interrupts make the design of any processor 
> significantly more complex, not to mention the software.
> 
> I think there was a discussion in one of the FPGA groups where a stack 
> CPU design was criticized for not including a semaphore instruction 
> which allowed inter-process communications to be implemented without 
> tons of work.  The "forth" solution would be to just not allow 
> interrupts and to not have multiprocessing!
<snip>

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" :) There are some that want interrupts for the next generation Propeller yet must forget somehow that each core is a CPU that can be dedicated to the task that would normally handled by the interrupt. One of those typical interrupts is the UART but with the Propeller for instance I can dedicate a core just to serial receive and/or transmit including the bit level implementation right through to handshaking and buffering etc. So the application is not "interrupted" for anything but only needs to access the buffers from the common hub RAM.

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!

Interrupts are great, that is if you only have a single core, which is not great at all these days. Multicore should not be thought of as parallel processing, as if even from the days of ILLIAC IV IIRC this was shown to be quite difficult/impossible to program. Multi-threading we understand though. Rather the cores are used IMO much as people are used within an organization, each specialized and looking after what they do best and everything runs smoothly.  

Interrupts? ah fooie!

(looks like the Propeller forums are back online, time to have some more fun)

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

#41620

On 8/30/2015 10:01 PM, pbjtech@gmail.com wrote:
>
> Interrupts are great, that is if you only have a single core, which
> is not great at all these days. Multicore should not be thought of as
> parallel processing, as if even from the days of ILLIAC IV IIRC this
> was shown to be quite difficult/impossible to program.
> Multi-threading we understand though. Rather the cores are used IMO
> much as people are used within an organization, each specialized and
> looking after what they do best and everything runs smoothly.
>
> Interrupts? ah fooie!
>
> (looks like the Propeller forums are back online, time to have some
> more fun)

I agree that multicore is a great way to program.  Interrupts are a 
terrible kludge created by the focus on building CPUs of ever increasing 
speed rather than using multiple cores assigned to a limited number of 
tasks.

But none of that precludes the need for semaphores.  How does the 
Parallax handle that?  Are there single instructions for semaphore 
operations?

-- 

Rick

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

#41622

rickman wrote:

> On 8/30/2015 10:01 PM, pbjtech@gmail.com wrote:
>>
>> Interrupts are great, that is if you only have a single core, which
>> is not great at all these days. Multicore should not be thought of as
>> parallel processing, as if even from the days of ILLIAC IV IIRC this
>> was shown to be quite difficult/impossible to program.
>> Multi-threading we understand though. Rather the cores are used IMO
>> much as people are used within an organization, each specialized and
>> looking after what they do best and everything runs smoothly.
>>
>> Interrupts? ah fooie!
>>
>> (looks like the Propeller forums are back online, time to have some
>> more fun)
> 
> I agree that multicore is a great way to program.  Interrupts are a
> terrible kludge created by the focus on building CPUs of ever increasing
> speed rather than using multiple cores assigned to a limited number of
> tasks.
> 
> But none of that precludes the need for semaphores.  How does the
> Parallax handle that?  Are there single instructions for semaphore
> operations?

It has something called "lock" that can be used similar like a semaphore. 
But I only once had the need for it.
Since each core has its own RAM and there is controlled access to common 
(hub) RAM there is not much need for semaphores. You usually use hub RAM for 
some kind of mailboxes or implement simple ring buffers which work without 
the need for synchronization.

One of the big advantages of this architecture is the clearly predictable 
timing also for access to common RAM.
For example if you write the software for some strange protocol (I did it 
for ARINC-429, serial 32bit, 100kBit/s, used in avionics) it will run on one 
CPU independent of what is going on in the rest. If you need more of the 
same interfaces just dedicate another CPU(s). With conventional interrupt 
driven single core CPUs you would have to think about mutual interference of 
the timing.
What I also found, that such programs get much simpler because each CPU just 
does _one_ task.

-- 
Reinhardt

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

#41621

On Sunday, August 30, 2015 at 7:01:59 PM UTC-7, pbj...@gmail.com wrote:
> 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!
> 
> Interrupts are great, that is if you only have a single core, which is not great at all these days. Multicore should not be thought of as parallel processing, as if even from the days of ILLIAC IV IIRC this was shown to be quite difficult/impossible to program. Multi-threading we understand though. Rather the cores are used IMO much as people are used within an organization, each specialized and looking after what they do best and everything runs smoothly.  
> 
> Interrupts? ah fooie!

I agree that having more than one processor makes things easier. The MiniForth had an 8032 on board with some 64MB of RAM (not a typo: 64MB not 64KB). The 8032 had a UART built in, which the MiniForth lacked, so the 8032 buffered the files from the desktop-computer and then fed the data to the MiniForth through parallel I/O --- this way the MiniForth could do the laser etching, but not have to store the big files in memory (it had limited memory) --- the timing was pretty precise on the motion-control, so you really can't have the processor interrupted by a UART while it is in the middle of etching.

I've been thinking about upgrading the FMITE so that it could be multi-core. It is pretty small, so on a big FPGA it there would be room for more than one of them. I would need semaphores so they don't step on each other's toes when accessing common RAM. Can you describe what is needed here? I think I need a primitive that can read and modify a memory location in one step.

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web