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

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

Open source CPU+open source toolchain

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

Contents

  Open source CPU+open source toolchain foxaudioresearch@gmail.com - 2015-07-29 17:57 -0700
    Re: Open source CPU+open source toolchain mentificium@gmail.com - 2015-07-29 18:36 -0700
      Re: Open source CPU+open source toolchain foxaudioresearch@gmail.com - 2015-07-29 19:15 -0700
    Re: Open source CPU+open source toolchain rickman <gnuarm@gmail.com> - 2015-07-30 01:40 -0400
      Re: Open source CPU+open source toolchain foxaudioresearch@gmail.com - 2015-07-30 07:11 -0700
      Re: Open source CPU+open source toolchain Jecel <jecel@merlintec.com> - 2015-07-30 09:39 -0700
      Re: Open source CPU+open source toolchain "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-30 21:22 -0400
        Re: Open source CPU+open source toolchain "Elizabeth D. Rather" <erather@forth.com> - 2015-07-30 20:56 -0500
          Re: Open source CPU+open source toolchain "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-30 22:05 -0400
            Re: Open source CPU+open source toolchain "Elizabeth D. Rather" <erather@forth.com> - 2015-07-31 09:47 -0500
              Re: Open source CPU+open source toolchain "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-31 23:57 -0400
                Re: Open source CPU+open source toolchain anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-01 13:07 +0000
                Re: Open source CPU+open source toolchain "Elizabeth D. Rather" <erather@forth.com> - 2015-08-01 10:37 -0500
    Re: Open source CPU+open source toolchain mfanyikazi@gmail.com - 2015-08-02 01:46 -0700
      Re: Open source CPU+open source toolchain foxaudioresearch@gmail.com - 2015-08-02 07:55 -0700
        Re: Open source CPU+open source toolchain rickman <gnuarm@gmail.com> - 2015-08-02 12:06 -0400
          Re: Open source CPU+open source toolchain foxaudioresearch@gmail.com - 2015-08-04 08:10 -0700
            Re: Open source CPU+open source toolchain rickman <gnuarm@gmail.com> - 2015-08-04 12:05 -0400
              Re: Open source CPU+open source toolchain foxaudioresearch@gmail.com - 2015-08-04 14:21 -0700
                Re: Open source CPU+open source toolchain rickman <gnuarm@gmail.com> - 2015-08-04 18:24 -0400
        Re: Open source CPU+open source toolchain Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-08-06 09:12 +0100

Page 1 of 2  [1] 2  Next page →

#40931 — Open source CPU+open source toolchain

This is a very nice testimonial to some Forth hacking.

http://hackaday.com/2015/07/28/open-source-fpga-toolchain-builds-cpu/

Youtube video is here https://www.youtube.com/watch?v=rdLgLCIDSk0

BF

[toc] | [next] | [standalone]

#40935

On Wednesday, July 29, 2015 at 5:57:13 PM UTC-7, foxaudio...@gmail.com wrote:
> This is a very nice testimonial to some Forth hacking.
> 
> http://hackaday.com/2015/07/28/open-source-fpga-toolchain-builds-cpu/
> [...]

Thank you for posting this. 

ATM
-- 
Hauptziel im Leben: technologische Singularitat bilden; 
Nebenziel: Chinesische Regierung stuerzen; 
Nebenziel: Nobelpreis in Gehirn-Physiologie gewinnen; 
Nebenziel: [X] Wiedervereinigung von Deutschland. 

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

#40936

On Wednesday, July 29, 2015 at 9:36:41 PM UTC-4, menti...@gmail.com wrote:
> On Wednesday, July 29, 2015 at 5:57:13 PM UTC-7, foxaudio...@gmail.com wrote:
> > This is a very nice testimonial to some Forth hacking.
> > 
> > http://hackaday.com/2015/07/28/open-source-fpga-toolchain-builds-cpu/
> > [...]
> 
> Thank you for posting this. 
> 
> ATM
> -- 
> Hauptziel im Leben: technologische Singularitat bilden; 
> Nebenziel: Chinesische Regierung stuerzen; 
> Nebenziel: Nobelpreis in Gehirn-Physiologie gewinnen; 
> Nebenziel: [X] Wiedervereinigung von Deutschland.

Bitte :-)

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

#40943

On 7/29/2015 8:57 PM, foxaudioresearch@gmail.com wrote:
> This is a very nice testimonial to some Forth hacking.
>
> http://hackaday.com/2015/07/28/open-source-fpga-toolchain-builds-cpu/
>
> Youtube video is here https://www.youtube.com/watch?v=rdLgLCIDSk0

Not intending to rain on anyone's parade, just asking a question.  Why 
does the forth community care if the FPGA development tools are open 
source?  The commercial tools don't really restrict the design of a CPU 
in any way does it?  The only real issue I've ever had with the 
commercial FPGA tools is the license which is a PITA to deal with once a 
year when it has to be renewed or when moving to a new machine.

Is it more a conceptual thing than a practical thing?

BTW, there is a very small board with the smallest FPGA on it which fits 
the pinout of a 8 pin DIP version of a CPU.  Here is the post I made 
about this in the FPGA related groups with a couple more links...

>> I am very impressed.  I was reading about Antti's incredibly tiny FPGA
>> project board and saw a mention of a FOSS FPGA toolchain.  Not just the
>> compiler, but the entire bitstream generation!
>>
>> http://hackaday.com/2015/07/03/hackaday-prize-entry-they-make-fpgas-that-small/
>>
>>
>> Several people have built on each other's work to provide "a fully open
>> source Verilog to bitstream development tool chain for the Lattice
>> iCE40LP with support for more devices in the works."
>>
>> http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-fpgas/
>>
>> https://github.com/cseed/arachne-pnr
>>
>> I haven't tried any of it yet, but I am very impressed that they are
>> reverse engineering the devices so that they can generate bit streams
>> and not rely on the vendor.
>
> I found another link relating to the tools called "IceStorm".
>
> http://www.clifford.at/icestorm/

Cross-posting to the FPGA group to get some cross-pollination.

-- 

Rick

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

#40972

On Thursday, July 30, 2015 at 1:40:18 AM UTC-4, rickman wrote:
> On 7/29/2015 8:57 PM, foxaudioresearch@gmail.com wrote:
> > This is a very nice testimonial to some Forth hacking.
> >
> > http://hackaday.com/2015/07/28/open-source-fpga-toolchain-builds-cpu/
> >
> > Youtube video is here https://www.youtube.com/watch?v=rdLgLCIDSk0
> 
> Not intending to rain on anyone's parade, just asking a question.  Why 
> does the forth community care if the FPGA development tools are open 
> source?  The commercial tools don't really restrict the design of a CPU 
> in any way does it?  The only real issue I've ever had with the 
> commercial FPGA tools is the license which is a PITA to deal with once a 
> year when it has to be renewed or when moving to a new machine.
> 
> Is it more a conceptual thing than a practical thing?
> 
> BTW, there is a very small board with the smallest FPGA on it which fits 
> the pinout of a 8 pin DIP version of a CPU.  Here is the post I made 
> about this in the FPGA related groups with a couple more links...
> 
> >> I am very impressed.  I was reading about Antti's incredibly tiny FPGA
> >> project board and saw a mention of a FOSS FPGA toolchain.  Not just the
> >> compiler, but the entire bitstream generation!
> >>
> >> http://hackaday.com/2015/07/03/hackaday-prize-entry-they-make-fpgas-that-small/
> >>
> >>
> >> Several people have built on each other's work to provide "a fully open
> >> source Verilog to bitstream development tool chain for the Lattice
> >> iCE40LP with support for more devices in the works."
> >>
> >> http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-fpgas/
> >>
> >> https://github.com/cseed/arachne-pnr
> >>
> >> I haven't tried any of it yet, but I am very impressed that they are
> >> reverse engineering the devices so that they can generate bit streams
> >> and not rely on the vendor.
> >
> > I found another link relating to the tools called "IceStorm".
> >
> > http://www.clifford.at/icestorm/
> 
> Cross-posting to the FPGA group to get some cross-pollination.
> 
> -- 
> 
> Rick

From my perspective I was more interested in the elegance of building a dual stack CPU in an FPGA, that was created with a very small amount verilog, the clarity of the SWAPFORTH code that built an interpreter/compiler that ran on that CPU and ultimately the excellent performance of the combination shown by the example of writing an I/O loop in a high level language that executed in 12 clock cycles. (12MHz clock, 1MHz output toggle)

However the creation of the open source verilog to bitstream tool chain seems no mean feat either, but I am not qualified to comment on that.

BF

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

#40976

On Thursday, July 30, 2015 at 2:40:18 AM UTC-3, rickman wrote:
> Not intending to rain on anyone's parade, just asking a question.  Why 
> does the forth community care if the FPGA development tools are open 
> source?  The commercial tools don't really restrict the design of a CPU 
> in any way does it?  The only real issue I've ever had with the 
> commercial FPGA tools is the license which is a PITA to deal with once a 
> year when it has to be renewed or when moving to a new machine.

There are two issues: future proofing and self hosting.

I still have a Spartan 2 board that I use, but none of the new Xilinx tools will deal with it. On the other hand, I can't run older versions of these tools on a modern Linux. I still have a window in which I can use that board with ISE 10 on Ubuntu 12.04 but that is closing as time goes by.

The second issue is that I can generate any CPU I want with these close tools but I can't run them on that CPU, only on x86 based PCs. So self hosting is not an option, which makes many interesting applications impossible (runtime hardware generation is the most obvious example).

-- Jecel

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

#40989

On Thu, 30 Jul 2015 01:40:11 -0400, rickman <gnuarm@gmail.com> wrote:

> Not intending to rain on anyone's parade, just asking a question.

So, you're willing to reign on the people's parade? ...  ;-)

> Why does the forth community care if the FPGA development tools are
> open source?

No ...  It's not open source that the Forth community wants.  It's free.
Not "free" as in "free" beer like open-source software, but "free" as
in truly free.  No cost.  No money.  No license.  No encumbrances.

Why?  Because, that's the way the Forth community has always done it.
Historically, they never copyrighted anything and gave everything they
created away for free.

You don't have to believe me.  Go look for yourself.

> Cross-posting to the FPGA group to get some cross-pollination.
>

Dropped.  Not interested in random spewage.


Rod Pemberton

-- 
Scientists now say we'll experience a mini-ice in 2030.
So, I guess we need more global warming today ...

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

#40991

On 7/30/15 8:22 PM, Rod Pemberton wrote:
> On Thu, 30 Jul 2015 01:40:11 -0400, rickman <gnuarm@gmail.com> wrote:
>
>> Not intending to rain on anyone's parade, just asking a question.
>
> So, you're willing to reign on the people's parade? ...  ;-)
>
>> Why does the forth community care if the FPGA development tools are
>> open source?
>
> No ...  It's not open source that the Forth community wants.  It's free.
> Not "free" as in "free" beer like open-source software, but "free" as
> in truly free.  No cost.  No money.  No license.  No encumbrances.
>
> Why?  Because, that's the way the Forth community has always done it.
> Historically, they never copyrighted anything and gave everything they
> created away for free.
>
> You don't have to believe me.  Go look for yourself.

"Always done it"? FORTH, Inc was founded in 1973. FIG didn't come along 
until 1977-8, largely inspired by the success of FORTH, Inc. (figFORTH 
was based on FORTH, Inc.'s microFORTH, which was introduced in 1977). In 
the 1980's, there was a thriving market in commercial Forths, with a 
number of vendors producing products of varying quality, including MPE. 
MPE and FORTH, Inc. are the only remaining commercial vendors, but our 
roots go way back.

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]

#40993

On Thu, 30 Jul 2015 21:56:55 -0400, Elizabeth D. Rather <erather@forth.com> wrote:

> On 7/30/15 8:22 PM, Rod Pemberton wrote:
>> On Thu, 30 Jul 2015 01:40:11 -0400, rickman <gnuarm@gmail.com> wrote:

>>> Not intending to rain on anyone's parade, just asking a question.
>>
>> So, you're willing to reign on the people's parade? ...  ;-)
>>
>>> Why does the forth community care if the FPGA development tools are
>>> open source?
>>
>> No ...  It's not open source that the Forth community wants.  It's free.
>> Not "free" as in "free" beer like open-source software, but "free" as
>> in truly free.  No cost.  No money.  No license.  No encumbrances.
>>
>> Why?  Because, that's the way the Forth community has always done it.
>> Historically, they never copyrighted anything and gave everything they
>> created away for free.
>>
>> You don't have to believe me.  Go look for yourself.
>
> "Always done it"? FORTH, Inc was founded in 1973. FIG didn't come along
> until 1977-8, largely inspired by the success of FORTH, Inc. (figFORTH
> was based on FORTH, Inc.'s microFORTH, which was introduced in 1977). In
> the 1980's, there was a thriving market in commercial Forths, with a
> number of vendors producing products of varying quality, including MPE.
> MPE and FORTH, Inc. are the only remaining commercial vendors, but our
> roots go way back.
>

Yes, but, unfortunately, those are insignificant percentage of the
overall Forth community over time.  fig-Forth took over.  fig-Forth
code and interpreters are still working to this day.  Most of the
commercial programs from 1970's and 1980's disappeared when their
companies went bankrupt.


RP

-- 
Scientists now say we'll experience a mini-ice in 2030.
So, I guess we need more global warming today ...

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

#41018

On 7/30/15 9:05 PM, Rod Pemberton wrote:
> On Thu, 30 Jul 2015 21:56:55 -0400, Elizabeth D. Rather
> <erather@forth.com> wrote:
>
>> On 7/30/15 8:22 PM, Rod Pemberton wrote:
>>> On Thu, 30 Jul 2015 01:40:11 -0400, rickman <gnuarm@gmail.com> wrote:
>
>>>> Not intending to rain on anyone's parade, just asking a question.
>>>
>>> So, you're willing to reign on the people's parade? ...  ;-)
>>>
>>>> Why does the forth community care if the FPGA development tools are
>>>> open source?
>>>
>>> No ...  It's not open source that the Forth community wants.  It's free.
>>> Not "free" as in "free" beer like open-source software, but "free" as
>>> in truly free.  No cost.  No money.  No license.  No encumbrances.
>>>
>>> Why?  Because, that's the way the Forth community has always done it.
>>> Historically, they never copyrighted anything and gave everything they
>>> created away for free.
>>>
>>> You don't have to believe me.  Go look for yourself.
>>
>> "Always done it"? FORTH, Inc was founded in 1973. FIG didn't come along
>> until 1977-8, largely inspired by the success of FORTH, Inc. (figFORTH
>> was based on FORTH, Inc.'s microFORTH, which was introduced in 1977). In
>> the 1980's, there was a thriving market in commercial Forths, with a
>> number of vendors producing products of varying quality, including MPE.
>> MPE and FORTH, Inc. are the only remaining commercial vendors, but our
>> roots go way back.
>>
>
> Yes, but, unfortunately, those are insignificant percentage of the
> overall Forth community over time.  fig-Forth took over.  fig-Forth
> code and interpreters are still working to this day.  Most of the
> commercial programs from 1970's and 1980's disappeared when their
> companies went bankrupt.

What, exactly are you basing this on? Last I heard, California Municipal 
Statistics was not only still alive and well but still using the 
software Chuck and I wrote in the late 70's (which has been enhanced and 
ported to a succession of more modern computers than the original 
PDP-11). The Saudi airport software is still functioning, although their 
computers are long since obsolete. We are in touch with several thousand 
of our long-term customers, and are doing occasional projects for many 
of them. Most of the electrical grid in the US is controlled by a 
network of processors running SwiftX, just to give one example. I'm sure 
MPE can quote a similar track record.

As for figFORTH, it didn't really survive Forth94 except for hobbyists. 
The current widely used free systems (gForth and Win32Forth) are 
original implementations.

Creative Solutions shut down due to Don Colburn's deteriorating health, 
but it was thriving. And LMI shut down to enable physician Ray Duncan 
(who always operated it as a part-time venture) to complete a residency 
in neonatology. I didn't actually hear of any bankrupcies.

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]

#41034

On Fri, 31 Jul 2015 10:47:20 -0400, Elizabeth D. Rather <erather@forth.com> wrote:

> On 7/30/15 9:05 PM, Rod Pemberton wrote:
>> On Thu, 30 Jul 2015 21:56:55 -0400, Elizabeth D. Rather
>> <erather@forth.com> wrote:
>>> On 7/30/15 8:22 PM, Rod Pemberton wrote:
>>>> On Thu, 30 Jul 2015 01:40:11 -0400, rickman <gnuarm@gmail.com> wrote:

>>>>> Not intending to rain on anyone's parade, just asking a question.
>>>>
>>>> So, you're willing to reign on the people's parade? ...  ;-)
>>>>
>>>>> Why does the forth community care if the FPGA development tools are
>>>>> open source?
>>>>
>>>> No ...  It's not open source that the Forth community wants.  It's free.
>>>> Not "free" as in "free" beer like open-source software, but "free" as
>>>> in truly free.  No cost.  No money.  No license.  No encumbrances.
>>>>
>>>> Why?  Because, that's the way the Forth community has always done it.
>>>> Historically, they never copyrighted anything and gave everything they
>>>> created away for free.
>>>>
>>>> You don't have to believe me.  Go look for yourself.
>>>
>>> "Always done it"? FORTH, Inc was founded in 1973. FIG didn't come along
>>> until 1977-8, largely inspired by the success of FORTH, Inc. (figFORTH
>>> was based on FORTH, Inc.'s microFORTH, which was introduced in 1977). In
>>> the 1980's, there was a thriving market in commercial Forths, with a
>>> number of vendors producing products of varying quality, including MPE.
>>> MPE and FORTH, Inc. are the only remaining commercial vendors, but our
>>> roots go way back.
>>>
>>
>> Yes, but, unfortunately, those are insignificant percentage of the
>> overall Forth community over time.  fig-Forth took over.  fig-Forth
>> code and interpreters are still working to this day.  Most of the
>> commercial programs from 1970's and 1980's disappeared when their
>> companies went bankrupt.
>
> What, exactly are you basing this on?

I'm basing that one the multiple hundreds of advertisements in Byte
magazine and Computer Shopper from the 1980's that sold the Forth
language and Forth solutions from companies that are no longer with us.

> Last I heard, California Municipal
> Statistics was not only still alive and well but still using the
> software Chuck and I wrote in the late 70's (which has been enhanced and
> ported to a succession of more modern computers than the original
> PDP-11). The Saudi airport software is still functioning, although their
> computers are long since obsolete. We are in touch with several thousand
> of our long-term customers, and are doing occasional projects for many
> of them. Most of the electrical grid in the US is controlled by a
> network of processors running SwiftX, just to give one example. I'm sure
> MPE can quote a similar track record.
>
> [...]
>
> Creative Solutions shut down due to Don Colburn's deteriorating health,
> but it was thriving. And LMI shut down to enable physician Ray Duncan
> (who always operated it as a part-time venture) to complete a residency
> in neonatology. I didn't actually hear of any bankrupcies.

Citing a few outlying cases of commercial Forth success doesn't change
the fact that the majority of Forth companies died or that the free
Forths are what survived and what people use.  It's like citing Apple as
proof the computer hardware industry from the 1980's is in good health
today, when numerous other computer companies died or exited that industry.

> As for figFORTH, it didn't really survive Forth94 except for hobbyists.
> The current widely used free systems (gForth and Win32Forth) are
> original implementations.

Yes, but a large portion of those fig-Forth systems are still with us
and available for x86 architecture.  I've collected 3 Forths for Windows
(gForth, Win32Forth, bigForth) and I think there is at least one other
free trial version I could get (MPE).  But, I have over a dozen for DOS,
mostly from the 1980's, e.g., from Tom Zimmer, Dr. C.H. Ting, Bill Muench,
etc and a bunch more as open-source C which compiles for Windows, Linux, DOS.


Rod Pemberton

-- 
Scientists now say we'll experience a mini-ice in 2030.
So, I guess we need more global warming today ...

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

#41039

"Rod Pemberton" <boo@fasdfrewar.cdm> writes:
>Citing a few outlying cases of commercial Forth success doesn't change
>the fact that the majority of Forth companies died or that the free
>Forths are what survived and what people use.  It's like citing Apple as
>proof the computer hardware industry from the 1980's is in good health
>today, when numerous other computer companies died or exited that industry.

The computer industry has much more revenue these days than in the
1980s, so overall I would say that it is a success story.  I don't
think that Forth is that successful (not the same multiplication
factor in revenue), but I would not be surprised if revenue today is
more than in the 1980s (but I have no way to tell).  For every new
technology there are lots of companies (startups) few of which exist
under that name a decade later; that's not a sign that the technology
is not a commercial success (nor that it is), just a sign that the
technology is young.

- 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.mpeforth.com/euroforth2015/euroforth2015.htm

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

#41042

On 7/31/15 10:57 PM, Rod Pemberton wrote:
> On Fri, 31 Jul 2015 10:47:20 -0400, Elizabeth D. Rather
> <erather@forth.com> wrote:
>
>> On 7/30/15 9:05 PM, Rod Pemberton wrote:
>>> On Thu, 30 Jul 2015 21:56:55 -0400, Elizabeth D. Rather
>>> <erather@forth.com> wrote:
>>>> On 7/30/15 8:22 PM, Rod Pemberton wrote:
>>>>> On Thu, 30 Jul 2015 01:40:11 -0400, rickman <gnuarm@gmail.com> wrote:
>
>>>>>> Not intending to rain on anyone's parade, just asking a question.
>>>>>
>>>>> So, you're willing to reign on the people's parade? ...  ;-)
>>>>>
>>>>>> Why does the forth community care if the FPGA development tools are
>>>>>> open source?
>>>>>
>>>>> No ...  It's not open source that the Forth community wants.  It's
>>>>> free.
>>>>> Not "free" as in "free" beer like open-source software, but "free" as
>>>>> in truly free.  No cost.  No money.  No license.  No encumbrances.
>>>>>
>>>>> Why?  Because, that's the way the Forth community has always done it.
>>>>> Historically, they never copyrighted anything and gave everything they
>>>>> created away for free.
>>>>>
>>>>> You don't have to believe me.  Go look for yourself.
>>>>
>>>> "Always done it"? FORTH, Inc was founded in 1973. FIG didn't come along
>>>> until 1977-8, largely inspired by the success of FORTH, Inc. (figFORTH
>>>> was based on FORTH, Inc.'s microFORTH, which was introduced in
>>>> 1977). In
>>>> the 1980's, there was a thriving market in commercial Forths, with a
>>>> number of vendors producing products of varying quality, including MPE.
>>>> MPE and FORTH, Inc. are the only remaining commercial vendors, but our
>>>> roots go way back.
>>>>
>>>
>>> Yes, but, unfortunately, those are insignificant percentage of the
>>> overall Forth community over time.  fig-Forth took over.  fig-Forth
>>> code and interpreters are still working to this day.  Most of the
>>> commercial programs from 1970's and 1980's disappeared when their
>>> companies went bankrupt.
>>
>> What, exactly are you basing this on?
>
> I'm basing that one the multiple hundreds of advertisements in Byte
> magazine and Computer Shopper from the 1980's that sold the Forth
> language and Forth solutions from companies that are no longer with us.

Most of the companies that produced the computers Forth ran on in the 
70's and 80's are no longer with us. Try taking a census of the 
advertisers in one of those magazines. I'll bet a lot of them are gone, 
not just Forth vendors.

>> Last I heard, California Municipal
>> Statistics was not only still alive and well but still using the
>> software Chuck and I wrote in the late 70's (which has been enhanced and
>> ported to a succession of more modern computers than the original
>> PDP-11). The Saudi airport software is still functioning, although their
>> computers are long since obsolete. We are in touch with several thousand
>> of our long-term customers, and are doing occasional projects for many
>> of them. Most of the electrical grid in the US is controlled by a
>> network of processors running SwiftX, just to give one example. I'm sure
>> MPE can quote a similar track record.
>>
>> [...]
>>
>> Creative Solutions shut down due to Don Colburn's deteriorating health,
>> but it was thriving. And LMI shut down to enable physician Ray Duncan
>> (who always operated it as a part-time venture) to complete a residency
>> in neonatology. I didn't actually hear of any bankrupcies.
>
> Citing a few outlying cases of commercial Forth success doesn't change
> the fact that the majority of Forth companies died or that the free
> Forths are what survived and what people use.  It's like citing Apple as
> proof the computer hardware industry from the 1980's is in good health
> today, when numerous other computer companies died or exited that industry.

The fact that computer companies died doesn't prove computers are 
obsolete. The computer industry is in fine health, it's just very 
different (Macs from Apple, PCs from many sources, and a zillion 
microprocessors). Forth has evolved, too.

>> As for figFORTH, it didn't really survive Forth94 except for hobbyists.
>> The current widely used free systems (gForth and Win32Forth) are
>> original implementations.
>
> Yes, but a large portion of those fig-Forth systems are still with us
> and available for x86 architecture.  I've collected 3 Forths for Windows
> (gForth, Win32Forth, bigForth) and I think there is at least one other
> free trial version I could get (MPE).

You can get free trial versions of SwiftForth and SwiftX from FORTH, 
Inc, too. None of those are based on figFORTH.

> But, I have over a dozen for DOS,
> mostly from the 1980's, e.g., from Tom Zimmer, Dr. C.H. Ting, Bill Muench,
> etc and a bunch more as open-source C which compiles for Windows, Linux,
> DOS.

I seriously doubt that any of those antique figFORTHs are being used for 
serious computing. figFORTH is a historical artifact. You could just as 
well collect 1980's C compilers, but you won't find many of them in use 
by professional programmers in contemporary projects.

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]

#41062

Ulrich Hoffmann https://github.com/uho already demonstrated this like 9 months ago when he used a rudimentary forth that I had developed on a simulator and actually made it work in a real FPGA environment on a Papilio pro FPGA board. The potential to run a small embeddable interactive forth on a FPGA is not a new concept but the J1 CPU is an excellent candidate for this line of work due to it's minimalistic nature however when you ever need things like multitasking then the j1 becomes a wee-bit hairy to work with , that's why I stopped development on it. You can see the stuff on gitub here https://github.com/samawati/j1eforth, great contribution by Ulrich Hoffmann by the way and also to James bowman for his j1 CPU in verilog which is awesome x2 ..

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

#41067

On Sunday, August 2, 2015 at 4:46:36 AM UTC-4, mfany...@gmail.com wrote:
> Ulrich Hoffmann https://github.com/uho already demonstrated this like 9 months ago when he used a rudimentary forth that I had developed on a simulator and actually made it work in a real FPGA environment on a Papilio pro FPGA board. The potential to run a small embeddable interactive forth on a FPGA is not a new concept but the J1 CPU is an excellent candidate for this line of work due to it's minimalistic nature however when you ever need things like multitasking then the j1 becomes a wee-bit hairy to work with , that's why I stopped development on it. You can see the stuff on gitub here https://github.com/samawati/j1eforth, great contribution by Ulrich Hoffmann by the way and also to James bowman for his j1 CPU in verilog which is awesome x2 ..

I read some things about multi-tasking and the J1. It is a thorny problem however is not the correct solution to add some support at the CPU level?  

Something like bigger stacks that could be segmented by task comes to mind.
I think the stack rollover is a possible threat but hey Forth people know how to keep the stack under control (at least in finished code) :)

Koopman indicates that you can run real Forth programs with 16 cells per stack.

Would that solve the multi-tasking problem for a specific maximum number of tasks?  (ie we would not be running UNIX on the thing, just some embedded programs)

BF

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

#41069

On 8/2/2015 10:55 AM, foxaudioresearch@gmail.com wrote:
> On Sunday, August 2, 2015 at 4:46:36 AM UTC-4, mfany...@gmail.com wrote:
>> Ulrich Hoffmann https://github.com/uho already demonstrated this like 9 months ago when he used a rudimentary forth that I had developed on a simulator and actually made it work in a real FPGA environment on a Papilio pro FPGA board. The potential to run a small embeddable interactive forth on a FPGA is not a new concept but the J1 CPU is an excellent candidate for this line of work due to it's minimalistic nature however when you ever need things like multitasking then the j1 becomes a wee-bit hairy to work with , that's why I stopped development on it. You can see the stuff on gitub here https://github.com/samawati/j1eforth, great contribution by Ulrich Hoffmann by the way and also to James bowman for his j1 CPU in verilog which is awesome x2 ..
>
> I read some things about multi-tasking and the J1. It is a thorny problem however is not the correct solution to add some support at the CPU level?
>
> Something like bigger stacks that could be segmented by task comes to mind.
> I think the stack rollover is a possible threat but hey Forth people know how to keep the stack under control (at least in finished code) :)
>
> Koopman indicates that you can run real Forth programs with 16 cells per stack.
>
> Would that solve the multi-tasking problem for a specific maximum number of tasks?  (ie we would not be running UNIX on the thing, just some embedded programs)

A very straight forward approach to multi-tasking is multi-processors. 
Every significant problem I have seen in embedded processing is due to a 
single processor being used to simultaneously run multiple tasks.  If 
you really require that then select a processor suitable to the job. 
With the low cost of transistors these days and the small size of stack 
processors, there is no little for difficult multi-tasking in an FPGA.

-- 

Rick

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

#41099

On Sunday, August 2, 2015 at 12:06:07 PM UTC-4, rickman wrote:
> On 8/2/2015 10:55 AM, foxaudioresearch@gmail.com wrote:
> > On Sunday, August 2, 2015 at 4:46:36 AM UTC-4, mfany...@gmail.com wrote:
> >> Ulrich Hoffmann https://github.com/uho already demonstrated this like 9 months ago when he used a rudimentary forth that I had developed on a simulator and actually made it work in a real FPGA environment on a Papilio pro FPGA board. The potential to run a small embeddable interactive forth on a FPGA is not a new concept but the J1 CPU is an excellent candidate for this line of work due to it's minimalistic nature however when you ever need things like multitasking then the j1 becomes a wee-bit hairy to work with , that's why I stopped development on it. You can see the stuff on gitub here https://github.com/samawati/j1eforth, great contribution by Ulrich Hoffmann by the way and also to James bowman for his j1 CPU in verilog which is awesome x2 ..
> >
> > I read some things about multi-tasking and the J1. It is a thorny problem however is not the correct solution to add some support at the CPU level?
> >
> > Something like bigger stacks that could be segmented by task comes to mind.
> > I think the stack rollover is a possible threat but hey Forth people know how to keep the stack under control (at least in finished code) :)
> >
> > Koopman indicates that you can run real Forth programs with 16 cells per stack.
> >
> > Would that solve the multi-tasking problem for a specific maximum number of tasks?  (ie we would not be running UNIX on the thing, just some embedded programs)
> 
> A very straight forward approach to multi-tasking is multi-processors. 
> Every significant problem I have seen in embedded processing is due to a 
> single processor being used to simultaneously run multiple tasks.  If 
> you really require that then select a processor suitable to the job. 
> With the low cost of transistors these days and the small size of stack 
> processors, there is no little for difficult multi-tasking in an FPGA.
> 
> -- 
> 
> Rick

That's a good point and a reasonable solution to the problem. It might not fly in specific commercial situations when improving and existing product with a big customer base or when the project specs are demanding that you keep the costs per unit to a magic low value. But I take your point.

It would still be interesting to me to expand the stack space in the J1 and use upper bits on the stack pointers as Base pointers to create a set of small stacks in the expanded stack space. For a finite number of tasks in an embedded project this is just more code, no new hardware.  No Verilog experience here, so there is time consumer for an old guy!

BF

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

#41101

On 8/4/2015 11:10 AM, foxaudioresearch@gmail.com wrote:
> On Sunday, August 2, 2015 at 12:06:07 PM UTC-4, rickman wrote:
>> On 8/2/2015 10:55 AM, foxaudioresearch@gmail.com wrote:
>>> On Sunday, August 2, 2015 at 4:46:36 AM UTC-4, mfany...@gmail.com
>>> wrote:
>>>> Ulrich Hoffmann https://github.com/uho already demonstrated
>>>> this like 9 months ago when he used a rudimentary forth that I
>>>> had developed on a simulator and actually made it work in a
>>>> real FPGA environment on a Papilio pro FPGA board. The
>>>> potential to run a small embeddable interactive forth on a FPGA
>>>> is not a new concept but the J1 CPU is an excellent candidate
>>>> for this line of work due to it's minimalistic nature however
>>>> when you ever need things like multitasking then the j1 becomes
>>>> a wee-bit hairy to work with , that's why I stopped development
>>>> on it. You can see the stuff on gitub here
>>>> https://github.com/samawati/j1eforth, great contribution by
>>>> Ulrich Hoffmann by the way and also to James bowman for his j1
>>>> CPU in verilog which is awesome x2 ..
>>>
>>> I read some things about multi-tasking and the J1. It is a thorny
>>> problem however is not the correct solution to add some support
>>> at the CPU level?
>>>
>>> Something like bigger stacks that could be segmented by task
>>> comes to mind. I think the stack rollover is a possible threat
>>> but hey Forth people know how to keep the stack under control (at
>>> least in finished code) :)
>>>
>>> Koopman indicates that you can run real Forth programs with 16
>>> cells per stack.
>>>
>>> Would that solve the multi-tasking problem for a specific maximum
>>> number of tasks?  (ie we would not be running UNIX on the thing,
>>> just some embedded programs)
>>
>> A very straight forward approach to multi-tasking is
>> multi-processors. Every significant problem I have seen in embedded
>> processing is due to a single processor being used to
>> simultaneously run multiple tasks.  If you really require that then
>> select a processor suitable to the job. With the low cost of
>> transistors these days and the small size of stack processors,
>> there is no little for difficult multi-tasking in an FPGA.
>>
>> --
>>
>> Rick
>
> That's a good point and a reasonable solution to the problem. It
> might not fly in specific commercial situations when improving and
> existing product with a big customer base or when the project specs
> are demanding that you keep the costs per unit to a magic low value.
> But I take your point.
>
> It would still be interesting to me to expand the stack space in the
> J1 and use upper bits on the stack pointers as Base pointers to
> create a set of small stacks in the expanded stack space. For a
> finite number of tasks in an embedded project this is just more code,
> no new hardware.  No Verilog experience here, so there is time
> consumer for an old guy!

Yes, that has been done before.  Someone in the c.a.fpga group (iirc) 
build a single processor with an 8 stage pipeline used so each stage of 
the pipe was a separate processor.  The additional logic was minimal and 
use of block RAM for memory made the stacks very efficient with the 
pipeline stage number identifying the processor and selecting the stack 
segment.  The pipelining allowed higher clock speeds which meant each 
processor ran roughly as fast as a single processor without the pipelining.

He was very excited about his design until someone got on his case about 
some feature that was missing which was important for writing "serious" 
code.  I don't recall what that was.

What I took away from the discussion is that we all have different 
expectations of these processors.  I want something simple with high 
visibility that I can understand the nuts and bolts of.  I also want it 
efficient across multiple architectures or easily optimized for them.  I 
don't need any features that allow writing an OS.  For others, they 
don't care much about the underlying CPU, only that it lets them do the 
software things they feel they need which often means lots of memory and 
OS support.

BTW, I see my post earlier ended a bit oddly.  I must have been editing 
it and hit the send before finishing.  I think it was supposed to end, 
"there is no NEED for difficult multi-tasking in an FPGA."

-- 

Rick

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

#41107

On Tuesday, August 4, 2015 at 12:05:07 PM UTC-4, rickman wrote:
> On 8/4/2015 11:10 AM, foxaudioresearch@gmail.com wrote:
> > On Sunday, August 2, 2015 at 12:06:07 PM UTC-4, rickman wrote:
> >> On 8/2/2015 10:55 AM, foxaudioresearch@gmail.com wrote:
> >>> On Sunday, August 2, 2015 at 4:46:36 AM UTC-4, mfany...@gmail.com
> >>> wrote:
> >>>> Ulrich Hoffmann https://github.com/uho already demonstrated
> >>>> this like 9 months ago when he used a rudimentary forth that I
> >>>> had developed on a simulator and actually made it work in a
> >>>> real FPGA environment on a Papilio pro FPGA board. The
> >>>> potential to run a small embeddable interactive forth on a FPGA
> >>>> is not a new concept but the J1 CPU is an excellent candidate
> >>>> for this line of work due to it's minimalistic nature however
> >>>> when you ever need things like multitasking then the j1 becomes
> >>>> a wee-bit hairy to work with , that's why I stopped development
> >>>> on it. You can see the stuff on gitub here
> >>>> https://github.com/samawati/j1eforth, great contribution by
> >>>> Ulrich Hoffmann by the way and also to James bowman for his j1
> >>>> CPU in verilog which is awesome x2 ..
> >>>
> >>> I read some things about multi-tasking and the J1. It is a thorny
> >>> problem however is not the correct solution to add some support
> >>> at the CPU level?
> >>>
> >>> Something like bigger stacks that could be segmented by task
> >>> comes to mind. I think the stack rollover is a possible threat
> >>> but hey Forth people know how to keep the stack under control (at
> >>> least in finished code) :)
> >>>
> >>> Koopman indicates that you can run real Forth programs with 16
> >>> cells per stack.
> >>>
> >>> Would that solve the multi-tasking problem for a specific maximum
> >>> number of tasks?  (ie we would not be running UNIX on the thing,
> >>> just some embedded programs)
> >>
> >> A very straight forward approach to multi-tasking is
> >> multi-processors. Every significant problem I have seen in embedded
> >> processing is due to a single processor being used to
> >> simultaneously run multiple tasks.  If you really require that then
> >> select a processor suitable to the job. With the low cost of
> >> transistors these days and the small size of stack processors,
> >> there is no little for difficult multi-tasking in an FPGA.
> >>
> >> --
> >>
> >> Rick
> >
> > That's a good point and a reasonable solution to the problem. It
> > might not fly in specific commercial situations when improving and
> > existing product with a big customer base or when the project specs
> > are demanding that you keep the costs per unit to a magic low value.
> > But I take your point.
> >
> > It would still be interesting to me to expand the stack space in the
> > J1 and use upper bits on the stack pointers as Base pointers to
> > create a set of small stacks in the expanded stack space. For a
> > finite number of tasks in an embedded project this is just more code,
> > no new hardware.  No Verilog experience here, so there is time
> > consumer for an old guy!
> 
> Yes, that has been done before.  Someone in the c.a.fpga group (iirc) 
> build a single processor with an 8 stage pipeline used so each stage of 
> the pipe was a separate processor.  The additional logic was minimal and 
> use of block RAM for memory made the stacks very efficient with the 
> pipeline stage number identifying the processor and selecting the stack 
> segment.  The pipelining allowed higher clock speeds which meant each 
> processor ran roughly as fast as a single processor without the pipelining.
> 
> He was very excited about his design until someone got on his case about 
> some feature that was missing which was important for writing "serious" 
> code.  I don't recall what that was.
> 
> What I took away from the discussion is that we all have different 
> expectations of these processors.  I want something simple with high 
> visibility that I can understand the nuts and bolts of.  I also want it 
> efficient across multiple architectures or easily optimized for them.  I 
> don't need any features that allow writing an OS.  For others, they 
> don't care much about the underlying CPU, only that it lets them do the 
> software things they feel they need which often means lots of memory and 
> OS support.
> 
> BTW, I see my post earlier ended a bit oddly.  I must have been editing 
> it and hit the send before finishing.  I think it was supposed to end, 
> "there is no NEED for difficult multi-tasking in an FPGA."
> 
> -- 
> 
> Rick

Thank you for the clarification Rick.  I suppose from my perspective Forth style round-robin, fast context switching multi-tasking is not "difficult" so I am biased. If you have not played with one I recommend it.  It's one of those strange cases where practice seems to work better than theory would indicate.

I built one for a 68HC11 board many years ago and it allowed me to do many cool things on that little chip and was not difficult at all. 

And I "completed" (made functional) the multi-tasker (that I paid for) for Hs/Forth for DOS and made some applications that some people said you could not do with DOS. (multi-terminal/multi-user application for example)

I am thinking, without experience mind you, that a cool little chip like J1 could benefit from the same functionality I liked with those old systems.

That being said if 5 or 6 little CPUs all fit on the FPGA that the project used, then I would seriously have to consider doing it your way. But to be honest without that experience in multi-processing I probably feel like it is more difficult than a the multi-tasker. Just my perception, not reality.

I have been told, that in Arabic, there is a saying:  "Everything is easy if you understand it.  If it isn't easy... you don't understand it."   

Sounds applicable to my "understanding" of many things, multi-processor programming among them. :-)

BF

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

#41110

On 8/4/2015 5:21 PM, foxaudioresearch@gmail.com wrote:
> On Tuesday, August 4, 2015 at 12:05:07 PM UTC-4, rickman wrote:
>> On 8/4/2015 11:10 AM, foxaudioresearch@gmail.com wrote:
>>> On Sunday, August 2, 2015 at 12:06:07 PM UTC-4, rickman wrote:
>>>> On 8/2/2015 10:55 AM, foxaudioresearch@gmail.com wrote:
>>>>> On Sunday, August 2, 2015 at 4:46:36 AM UTC-4,
>>>>> mfany...@gmail.com wrote:
>>>>>> Ulrich Hoffmann https://github.com/uho already
>>>>>> demonstrated this like 9 months ago when he used a
>>>>>> rudimentary forth that I had developed on a simulator and
>>>>>> actually made it work in a real FPGA environment on a
>>>>>> Papilio pro FPGA board. The potential to run a small
>>>>>> embeddable interactive forth on a FPGA is not a new concept
>>>>>> but the J1 CPU is an excellent candidate for this line of
>>>>>> work due to it's minimalistic nature however when you ever
>>>>>> need things like multitasking then the j1 becomes a wee-bit
>>>>>> hairy to work with , that's why I stopped development on
>>>>>> it. You can see the stuff on gitub here
>>>>>> https://github.com/samawati/j1eforth, great contribution
>>>>>> by Ulrich Hoffmann by the way and also to James bowman for
>>>>>> his j1 CPU in verilog which is awesome x2 ..
>>>>>
>>>>> I read some things about multi-tasking and the J1. It is a
>>>>> thorny problem however is not the correct solution to add
>>>>> some support at the CPU level?
>>>>>
>>>>> Something like bigger stacks that could be segmented by task
>>>>> comes to mind. I think the stack rollover is a possible
>>>>> threat but hey Forth people know how to keep the stack under
>>>>> control (at least in finished code) :)
>>>>>
>>>>> Koopman indicates that you can run real Forth programs with
>>>>> 16 cells per stack.
>>>>>
>>>>> Would that solve the multi-tasking problem for a specific
>>>>> maximum number of tasks?  (ie we would not be running UNIX on
>>>>> the thing, just some embedded programs)
>>>>
>>>> A very straight forward approach to multi-tasking is
>>>> multi-processors. Every significant problem I have seen in
>>>> embedded processing is due to a single processor being used to
>>>> simultaneously run multiple tasks.  If you really require that
>>>> then select a processor suitable to the job. With the low cost
>>>> of transistors these days and the small size of stack
>>>> processors, there is no little for difficult multi-tasking in
>>>> an FPGA.
>>>>
>>>> --
>>>>
>>>> Rick
>>>
>>> That's a good point and a reasonable solution to the problem. It
>>> might not fly in specific commercial situations when improving
>>> and existing product with a big customer base or when the project
>>> specs are demanding that you keep the costs per unit to a magic
>>> low value. But I take your point.
>>>
>>> It would still be interesting to me to expand the stack space in
>>> the J1 and use upper bits on the stack pointers as Base pointers
>>> to create a set of small stacks in the expanded stack space. For
>>> a finite number of tasks in an embedded project this is just more
>>> code, no new hardware.  No Verilog experience here, so there is
>>> time consumer for an old guy!
>>
>> Yes, that has been done before.  Someone in the c.a.fpga group
>> (iirc) build a single processor with an 8 stage pipeline used so
>> each stage of the pipe was a separate processor.  The additional
>> logic was minimal and use of block RAM for memory made the stacks
>> very efficient with the pipeline stage number identifying the
>> processor and selecting the stack segment.  The pipelining allowed
>> higher clock speeds which meant each processor ran roughly as fast
>> as a single processor without the pipelining.
>>
>> He was very excited about his design until someone got on his case
>> about some feature that was missing which was important for writing
>> "serious" code.  I don't recall what that was.
>>
>> What I took away from the discussion is that we all have different
>> expectations of these processors.  I want something simple with
>> high visibility that I can understand the nuts and bolts of.  I
>> also want it efficient across multiple architectures or easily
>> optimized for them.  I don't need any features that allow writing
>> an OS.  For others, they don't care much about the underlying CPU,
>> only that it lets them do the software things they feel they need
>> which often means lots of memory and OS support.
>>
>> BTW, I see my post earlier ended a bit oddly.  I must have been
>> editing it and hit the send before finishing.  I think it was
>> supposed to end, "there is no NEED for difficult multi-tasking in
>> an FPGA."
>>
>> --
>>
>> Rick
>
> Thank you for the clarification Rick.  I suppose from my perspective
> Forth style round-robin, fast context switching multi-tasking is not
> "difficult" so I am biased. If you have not played with one I
> recommend it.  It's one of those strange cases where practice seems
> to work better than theory would indicate.
>
> I built one for a 68HC11 board many years ago and it allowed me to do
> many cool things on that little chip and was not difficult at all.
>
> And I "completed" (made functional) the multi-tasker (that I paid
> for) for Hs/Forth for DOS and made some applications that some people
> said you could not do with DOS. (multi-terminal/multi-user
> application for example)

Sure, but the tasker is not the hard part of multitasking.  If you have 
a simple set of tasks to do multitasking can be as simple as running 
each task in turn with no worries.  But if the multitasking is more 
complex the whole environment has to be considered.

In fact, I think it was the intertask communications that was the hard 
part even with multiple processors.  I seem to recall it requires an 
instruction to allow manipulation of a semaphore.


> I am thinking, without experience mind you, that a cool little chip
> like J1 could benefit from the same functionality I liked with those
> old systems.
>
> That being said if 5 or 6 little CPUs all fit on the FPGA that the
> project used, then I would seriously have to consider doing it your
> way. But to be honest without that experience in multi-processing I
> probably feel like it is more difficult than a the multi-tasker. Just
> my perception, not reality.

The pipelined multiprocessor design with 8 logical processors was as 
much an easy way to use the hardware as it was a way to provide more 
MIPS.  To use pipelining to make a single processor run faster creates 
pipeline stalls when the execution takes a turn.  The 8 logical 
processors are not pipelined yielding 8 processors with N MIPS each vs. 
1 processor with 8*M minus some factor for the branch stalls.  None of 
this takes much more logic than a single processor, which if a stack 
processor can be very small compared to the fancy RISC type designs.

If you truly need multitasking, giving each task it's own processor can 
work very well.  But it all depends on the tasks.  If 90% of your 
processing is in one task, then this won't help much.

-- 

Rick

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web