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

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

Rockwell R65F11

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

Contents

  Rockwell R65F11 Derek Simmons <dereks314@gmail.com> - 2015-03-23 15:52 -0700
    Re: Rockwell R65F11 "WJ" <w_a_x_man@yahoo.com> - 2015-03-23 23:46 +0000
      Re: Rockwell R65F11 Jason Damisch <jasondamisch@yahoo.com> - 2015-03-23 17:24 -0700
    Re: Rockwell R65F11 Derek Simmons <dereks314@gmail.com> - 2015-03-23 17:33 -0700
      Re: Rockwell R65F11 visualforth@rocketmail.com - 2015-03-24 21:44 -0700
        Re: Rockwell R65F11 hughaguilar96@gmail.com - 2015-03-25 14:47 -0700
          Re: Rockwell R65F11 rickman <gnuarm@gmail.com> - 2015-03-25 18:42 -0400
        Re: Rockwell R65F11 Derek Simmons <dereks314@gmail.com> - 2015-03-25 19:43 -0700
        Re: Rockwell R65F11 Derek Simmons <dereks314@gmail.com> - 2015-03-25 20:08 -0700
          Re: Rockwell R65F11 visualforth@rocketmail.com - 2015-03-25 21:41 -0700
            Re: Rockwell R65F11 hughaguilar96@gmail.com - 2015-03-25 22:43 -0700
              Re: Rockwell R65F11 Derek Simmons <dereks314@gmail.com> - 2015-03-26 11:42 -0700
                Re: Rockwell R65F11 "WJ" <w_a_x_man@yahoo.com> - 2015-03-26 20:50 +0000
                  Re: Rockwell R65F11 visualforth@rocketmail.com - 2015-03-26 18:07 -0700
              Re: Rockwell R65F11 visualforth@rocketmail.com - 2015-03-26 13:11 -0700
                Re: Rockwell R65F11 hughaguilar96@gmail.com - 2015-03-26 21:11 -0700
                  Re: Rockwell R65F11 visualforth@rocketmail.com - 2015-03-26 22:14 -0700
                    Re: Rockwell R65F11 hughaguilar96@gmail.com - 2015-03-28 16:57 -0700
              Re: Rockwell R65F11 hughaguilar96@gmail.com - 2015-03-28 17:18 -0700
                Re: Rockwell R65F11 Derek Simmons <dereks314@gmail.com> - 2015-03-31 11:05 -0700
                  Re: Rockwell R65F11 Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-02 10:20 +0100
                    Re: Rockwell R65F11 albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-02 11:25 +0000
                      Re: Rockwell R65F11 Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-03 12:16 +0100
                        Re: Rockwell R65F11 Paul Rubin <no.email@nospam.invalid> - 2015-04-03 09:23 -0700
                          Re: Rockwell R65F11 Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-06 10:51 +0100
                            Re: Rockwell R65F11 Paul Rubin <no.email@nospam.invalid> - 2015-04-06 13:55 -0700
                              Re: Rockwell R65F11 Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-07 20:18 +0100
                                Re: Rockwell R65F11 Paul Rubin <no.email@nospam.invalid> - 2015-04-07 19:02 -0700
                  Re: Rockwell R65F11 Paul Rubin <no.email@nospam.invalid> - 2015-04-02 16:10 -0700
                    Re: Rockwell R65F11 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-04-02 22:57 -0700
                      Re: Rockwell R65F11 Paul Rubin <no.email@nospam.invalid> - 2015-04-03 00:06 -0700
                      Re: Rockwell R65F11 hughaguilar96@gmail.com - 2015-04-03 09:00 -0700
    Re: Rockwell R65F11 Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-08 08:27 +0100
      Re: Rockwell R65F11 Derek Simmons <dereks314@gmail.com> - 2015-04-24 12:22 -0700
        Re: Rockwell R65F11 hughaguilar96@gmail.com - 2015-04-24 13:38 -0700
          Re: Rockwell R65F11 Derek Simmons <dereks314@gmail.com> - 2015-04-25 08:35 -0700

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

#37829

On Tue, 31 Mar 2015 11:05:43 -0700 (PDT)
Derek Simmons <dereks314@gmail.com> wrote:

> It would be nice if somebody would create a version of Python that didn't depend on an operating system. I know that their are a couple of statup projects that advertise that it is 'Python Porcessor' but I suspect it is embedded LINUX. 

There are a few real ones, but some only define a subset of 
the python engine bytecodes.  

Since Python runs on a byte token stack engine, writing this 
in Forth would look easy.  Especially as you don't need to 
do the compiler, just use the PC version of Python. 

The size of the task starts to grow when you notice that when 
the python byte code engine does a DUP to copy an integer, 
it not only copies the integer object reference, but must also 
bump the object reference count. 

I think it would be great to have the python byte code engine 
written in Forth.  Like Forth, python functions can return 
multiple items, and source code looks clean and simple. 

My favourite python feature is the unconstrained integers. A 
256 bit initialisation constant for FPGA memory can be operated 
on just like any other integer. 

When can we start? 

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

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

#37836

In article <20150402102012.66a1452d@T60A>,
Jan Coombs  <Jan-54 <jenfhaomndgfwutc@murmic.plus.com> wrote:
>On Tue, 31 Mar 2015 11:05:43 -0700 (PDT)
>Derek Simmons <dereks314@gmail.com> wrote:
>
>> It would be nice if somebody would create a version of Python that
>didn't depend on an operating system. I know that their are a couple of
>statup projects that advertise that it is 'Python Porcessor' but I
>suspect it is embedded LINUX.
>
>There are a few real ones, but some only define a subset of
>the python engine bytecodes.
>
>Since Python runs on a byte token stack engine, writing this
>in Forth would look easy.  Especially as you don't need to
>do the compiler, just use the PC version of Python.
>
>The size of the task starts to grow when you notice that when
>the python byte code engine does a DUP to copy an integer,
>it not only copies the integer object reference, but must also
>bump the object reference count.
>
>I think it would be great to have the python byte code engine
>written in Forth.  Like Forth, python functions can return
>multiple items, and source code looks clean and simple.

That part is easy. The difficult part is where performance matters.
There the {ythoneers have their libraries written in C.
A graphics library, or a serial communication library working
transparently the same on several OS-es are the problem.
Replacing C as an implementation language for e.g. tcl is
something not even major Forth implementors aspire to.

>
>My favourite python feature is the unconstrained integers. A
>256 bit initialisation constant for FPGA memory can be operated
>on just like any other integer.
>
>When can we start?

With what, a proof-of-concept Python interpreter in Forth, like
we have a Pascal compiler and a BASIC interpreter?

>
>Jan Coombs.
>--
>email valid, else fix dots and hyphen
>jan4clf2014@murrayhyphenmicroftdotcodotuk
>
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#37882

On 02 Apr 2015 11:25:42 GMT
albert@spenarnc.xs4all.nl (Albert van der Horst) wrote:

> In article <20150402102012.66a1452d@T60A>,
> Jan Coombs  <Jan-54 <jenfhaomndgfwutc@murmic.plus.com> wrote:
   . . .
> >
> >I think it would be great to have the python byte code engine
> >written in Forth.  Like Forth, python functions can return
> >multiple items, and source code looks clean and simple.
> 
> That part is easy. The difficult part is where performance matters.
> There the {ythoneers have their libraries written in C.
> A graphics library, or a serial communication library working
> transparently the same on several OS-es are the problem.
> Replacing C as an implementation language for e.g. tcl is
> something not even major Forth implementors aspire to.

Agreed, but if you had a Forth chip, and wanted to sell it to 
a wide audience, then Python might make it look more attractive, 
and then you'd be doing the os/system code in Forth, not C. 

 
> >When can we start?
> 
> With what, a proof-of-concept Python interpreter in Forth, like
> we have a Pascal compiler and a BASIC interpreter?

Yes, "Build one to throw away", especially if it's worth it. Also, 
your toy might be my inspirational start point. 


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

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

#37886

Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> writes:
> Agreed, but if you had a Forth chip, and wanted to sell it to 
> a wide audience, then Python might make it look more attractive, 
> and then you'd be doing the os/system code in Forth, not C. 

Current concepts of Forth chips that I know of are for small embedded
programs, nothing remotely as complicated as a Python interpreter.  The
stack hardware lets you make a very simple and tiny CPU.  I believe even
Micropython needs around a megabyte of ram.  Once you're willing to use
that much ram, you might as well use a conventional processor with
registers.

It's a mistake to think of CPython byte code as something like token
threaded Forth, where the byte codes correspond to simple combinations
of machine instructions.  Some of them do complicated things like load a
Python source file into the interpreter.  Finally, a lot of the Python
ecosystem (even included datatypes like lists and dictionaries) is
library modules written in C that get loaded into the Python
interpreter.  If you want people to be able to program your Forth Python
in a familiar Python style, you'll have to implement all those modules.
Doable in principle I suppose, but hard to justify as I see it.

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

#38003

On Fri, 03 Apr 2015 09:23:41 -0700
Paul Rubin <no.email@nospam.invalid> wrote:

> Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> writes:
> > Agreed, but if you had a Forth chip, and wanted to sell it to 
> > a wide audience, then Python might make it look more attractive, 
> > and then you'd be doing the os/system code in Forth, not C. 
> 
> Current concepts of Forth chips that I know of are for small embedded
> programs, nothing remotely as complicated as a Python interpreter.  The
> stack hardware lets you make a very simple and tiny CPU.  I believe even
> Micropython needs around a megabyte of ram.  Once you're willing to use
> that much ram, you might as well use a conventional processor with
> registers. 

You startled me, so I checked their site, and now I'd like to have 
a MicroPython to play with!  

The ARM processor has 1MB of Flash,  and 196kB RAM, and the current 
download size seems to be ~260kB. [1][2]  

Perhaps my other comments were too 'forward looking'

> It's a mistake to think of CPython byte code as something like token
> threaded Forth, where the byte codes correspond to simple combinations
> of machine instructions.  Some of them do complicated things like load a
> Python source file into the interpreter.  Finally, a lot of the Python
> Python source file into the interpreter. 

Looking at opcode.h in Python, it seems to me that only about a third of 
the opcodes reference high level functions.  It is not uncommon for a 
processor to trap unimplemented instructions and run software, so a 
custom python (stack) engine could do the same. 

>                                       Finally, a lot of the Python
> ecosystem (even included datatypes like lists and dictionaries) is
> library modules written in C that get loaded into the Python
> interpreter.  If you want people to be able to program your Forth Python
> in a familiar Python style, you'll have to implement all those modules.
> Doable in principle I suppose, but hard to justify as I see it. 

If there was an ideal engine, it could start work in small embedded 
systems with no libraries, then, as it grew then libraries would be 
translated or written.

Norbert Feurle? started a simple Python stack engine project. [3]

As I see it, the picture is much lighter than you painted, but 
possibly much darker than I imagine. 

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

[1] http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN1035/PF252144
[2] http://www.micropython.org/download/
[3] http://old.myhdl.org/doku.php/projects:python_hardware_processor

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

#38023

Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> writes:
>> I believe even Micropython needs around a megabyte of ram. 
> You startled me,...
> The ARM processor has 1MB of Flash,  and 196kB RAM, and the current 
> download size seems to be ~260kB. 

Hmm, yeah, it looks like I got confused, I checked again and the person
had actually told me the program space used is around 256k and the ram
usage varies.

Still, Python aims more for programming comfort (comfort is good) than
minimizing memory footprint.  Picobit and Microscheme might be of
interest (also Lua) if you want smaller languages.

> If there was an ideal engine, it could start work in small embedded 
> systems with no libraries, then, as it grew then libraries would be 
> translated or written.

Lists, dictionaries, strings, and a few other types are very fundamental
to Python so you'd need them, though I guess they are doable.

The bytecode stuff isn't inherent to Python at all, it's just a detail
of how one particular implementation works.  That happens to be the most
widely used implementation (CPython), but the most advanced
implementation (PyPy) has a JIT compiler.

You might also look at Lua (uses a register-based VM), Picobit (uses
bytecode), and Microscheme (generates AVR 8-bit native code but
currently has no garbage collector).

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

#38049

On Mon, 06 Apr 2015 13:55:07 -0700
Paul Rubin <no.email@nospam.invalid> wrote:

> Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> writes:
> > If there was an ideal engine, it could start work in small embedded 
> > systems with no libraries, then, as it grew then libraries would be 
> > translated or written.
> 
> Lists, dictionaries, strings, and a few other types are very fundamental
> to Python so you'd need them, though I guess they are doable. 

Only met Lists and Dictionaries recently when starting to use Python for 
hardware design, so could probably do simple embedded without them.
 
> The bytecode stuff isn't inherent to Python at all, it's just a detail
> of how one particular implementation works.  That happens to be the most
> widely used implementation (CPython), but the most advanced
> implementation (PyPy) has a JIT compiler. 

Yes, PyPy is magnificent.  It can brings the performance of the MyHDL 
simulator up to the same speed as tools written in other languages. [1] 

> You might also look at Lua (uses a register-based VM), Picobit (uses
> bytecode), and Microscheme (generates AVR 8-bit native code but
> currently has no garbage collector).

I'd heard of Lua, but not looked at the VMs before, thanks.  Picobit 
was most interesting, with it's inherent support for bignums.  I'm 
not sure how to handle arrays or stack frames containing bignums. 

Can algorithms which operate on arrays be re-arranged to operate on 
streams of data (bignums). This adds compression, compared with using 
an very large array, especially if much of the data is close to zero. 
This then could reduce required memory bandwidth. 

For example, might an FFT re-order data on each pass ready for the next 
pass by stream division?  

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

[1] http://old.myhdl.org/doku.php/performance

Lua VM "Stack-machine instructions are too low level"
http://www.inf.puc-rio.br/~roberto/talks/lua-ll3.pdf

Picobit VM - bignums stored in heap
http://www.ccs.neu.edu/home/stamourv/papers/picobit.pdf

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

#38053

Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> writes:
> Only met Lists and Dictionaries recently when starting to use Python for 
> hardware design, so could probably do simple embedded without them.

That is unfortunately impossible: Python semantics are defined in terms
of lists and dictionaries and some other such things, and if you don't
have them, you don't have Python.  For example, if you say a = b + c,
you can't treat that as an arithmetic addition, it's actually a call on
the __add__ method of whatever class b is a member of.  And method
lookup is defined in terms of a method dictionary belonging to the
class.

> I'd heard of Lua, but not looked at the VMs before, thanks.  Picobit 
> was most interesting, with it's inherent support for bignums.  I'm 
> not sure how to handle arrays or stack frames containing bignums. 

In Picobit?  They are treated as references to garbage collected memory
just like anything else.

> Can algorithms which operate on arrays be re-arranged to operate on 
> streams of data (bignums).

I'm not sure what you mean by that: Python's native integers are bignums
so no re-arrangement is needed.  You can have arrays of bignums.

> For example, might an FFT re-order data on each pass ready for the next 
> pass by stream division?  

You can reorder arrays of bignums (or visit them in butterfly order)
just like any other array.  But, are you talking about some kind of
bignum integer FFT?  Usually I think of FFT as a fixed point or floating
point operation.

There is also a numerics library for Python (www.numpy.org) that does
FFT's among other things.

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

#37854

Derek Simmons <dereks314@gmail.com> writes:
> It would be nice if somebody would create a version of Python that
> didn't depend on an operating system.

See: www.micropython.org

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

#37874

vineri, 3 aprilie 2015, 02:10:54 UTC+3, Paul Rubin a scris:
> Derek Simmons <dereks314@gmail.com> writes:
> > It would be nice if somebody would create a version of Python that
> > didn't depend on an operating system.
> 
> See: www.micropython.org

I wonder what's the speed of this thing. A similar approach but with javascript instead of python admitted that an empty loop runs at 10K iterations/second and a led toggle reach 3KHz... This is embarrassing even if you are allowed to write your own primitives in C. In this way you will end writing about everything in C and use the scripting language for almost nothing.

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

#37877

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>> See: www.micropython.org
> I wonder what's the speed of this thing. A similar approach but with
> javascript instead of python admitted that an empty loop runs at 10K
> iterations/second and a led toggle reach 3KHz... 

I haven't tested micropython but it's aimed at fairly powerful 32-bit
cpu's that likely run at at 100 mhz or more.  CPython code is typically
around 50x slower than C code (CPython is not very efficient) so you'd
maybe get a couple million loops per second out, plenty for lots of
purposes.

Depending on what you're doing, even 10k/sec might be ok.  Tons of
useful stuff was written in 8-bit BASIC back in the day, and 10k
loops/sec would have been blazing fast on those old machines.

> This is embarrassing even if you are allowed to write your own
> primitives in C. In this way you will end writing about everything in
> C and use the scripting language for almost nothing.

Python is basically a scripting wrapper around a bunch of C functions.
Writing the low level stuff in C and the high level stuff in Python is a
good combination.

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

#37885

On Thursday, April 2, 2015 at 10:57:20 PM UTC-7, Raimond Dragomir wrote:
> vineri, 3 aprilie 2015, 02:10:54 UTC+3, Paul Rubin a scris:
> > Derek Simmons <dereks314@gmail.com> writes:
> > > It would be nice if somebody would create a version of Python that
> > > didn't depend on an operating system.
> > 
> > See: www.micropython.org
> 
> I wonder what's the speed of this thing. A similar approach but with javascript instead of python admitted that an empty loop runs at 10K iterations/second and a led toggle reach 3KHz... This is embarrassing even if you are allowed to write your own primitives in C. In this way you will end writing about everything in C and use the scripting language for almost nothing.

When I was still programming in Factor, I discussed micro-controllers with Slava Pestov. Even at that time, Factor was upwards of an order of magnitude faster than Python. He said that his goal was for Factor to replace Java as the language of smart-phones. As for micro-controllers, the smallest he foresaw Factor ever running on, was the ColdFire --- he was mostly focused on the ARM --- he immediately dismissed the eZ80. My suggestion was a dual-processor board with the PIC24 running Forth and doing motion-control and the eZ80 running Factor and communicating with the outside world over the internet (the eZ80's big memory would be used to hold files) --- I was thinking about the laser-etcher that has to have files uploaded into it (Testra had an 8032 processor with 64MB of RAM) but also has to be fast --- I much prefer a system with two small processors rather than one big processor.

I think that Factor will never compete against Forth or C for real-time micro-controllers. It might be used in smart-phones because they aren't real-time, and they have very powerful processors and a lot of memory, pretty comparable to desktop-computers except much smaller physically.

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

#38055

On Mon, 23 Mar 2015 15:52:55 -0700 (PDT)
Derek Simmons <dereks314@gmail.com> wrote:

> 
> I'm looking for 4 or at least 1 R65F11. If anybody has stash or you know somebody I can contact I would be grateful.

If you don't get any chips, maybe there is an FPGA solution 
for replacement hardware?  I'm about to start serious testing 
of a CDP1802 system-on-chip, and the 6502 is not disimilar. 

BTW, sorry for helping with so much thread deviation...

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

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

#38580

On Wednesday, April 8, 2015 at 3:27:44 AM UTC-4, Jan Coombs wrote:
> On Mon, 23 Mar 2015 15:52:55 -0700 (PDT)
> Derek Simmons <dereks314@gmail.com> wrote:
> 
> > 
> > I'm looking for 4 or at least 1 R65F11. If anybody has stash or you know somebody I can contact I would be grateful.
> 
> If you don't get any chips, maybe there is an FPGA solution 
> for replacement hardware?  I'm about to start serious testing 
> of a CDP1802 system-on-chip, and the 6502 is not disimilar. 
> 
> BTW, sorry for helping with so much thread deviation...
> 
> Jan Coombs.
> -- 
> email valid, else fix dots and hyphen
> jan4clf2014@murrayhyphenmicroftdotcodotuk

You kind of hit the nail on the head. We are in kind of in a resource gathering phase. The first part is to get the Rockwell FORTH system working. The next phase would be to develop a FPGA based system. The long term goals is to replace the floppies with Flash memory cards, replace the software serial port with a hardware serial port, and the longest term goal is to replace the R6500 with an 65816 or similar. 

We've considered Jupiter Ace with GIDE but somebody already had done a lot of the work with the ZET project. we thought we were a head of the game by already having a FORTH development system.

In our circles we caught the attention of some professors. If we get a working FPGA system they would be interested in using for instructional purposes.

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

#38583

On Friday, April 24, 2015 at 12:22:16 PM UTC-7, Derek Simmons wrote:
> On Wednesday, April 8, 2015 at 3:27:44 AM UTC-4, Jan Coombs wrote:
> > On Mon, 23 Mar 2015 15:52:55 -0700 (PDT)
> > Derek Simmons <dereks314@gmail.com> wrote:
> > 
> > > 
> > > I'm looking for 4 or at least 1 R65F11. If anybody has stash or you know somebody I can contact I would be grateful.
> > 
> > If you don't get any chips, maybe there is an FPGA solution 
> > for replacement hardware?  I'm about to start serious testing 
> > of a CDP1802 system-on-chip, and the 6502 is not disimilar. 
> > 
> > BTW, sorry for helping with so much thread deviation...
> > 
> > Jan Coombs.
> > -- 
> > email valid, else fix dots and hyphen
> > jan4clf2014@murrayhyphenmicroftdotcodotuk
> 
> You kind of hit the nail on the head. We are in kind of in a resource gathering phase. The first part is to get the Rockwell FORTH system working. The next phase would be to develop a FPGA based system. The long term goals is to replace the floppies with Flash memory cards, replace the software serial port with a hardware serial port, and the longest term goal is to replace the R6500 with an 65816 or similar. 
> 
> We've considered Jupiter Ace with GIDE but somebody already had done a lot of the work with the ZET project. we thought we were a head of the game by already having a FORTH development system.
> 
> In our circles we caught the attention of some professors. If we get a working FPGA system they would be interested in using for instructional purposes.

The 6502, 6511 and 65c02 were cool processors, but they had some design flaws. If you do make an FPGA that runs this machine-code, I recommend that you also add some new instructions that can be used by progressive 6502 programmers to avoid the problems of old.

For example, the 65c02 had a JMP indexed-indirect instruction, but it used X rather than Y. Any Forth programmer could have told the designers that Y should be used for the index because X is already being used as the data-stack pointer. Provide another similar instruction that uses Y, which will help to implement a byte-code Forth efficiently. A good byte-code Forth should provide extreme memory-efficiency --- this might actually make your processor useful in the real-world. 

It would be a good idea to write a byte-code Forth for the 65c02 first (using the new JMP instruction I described above), using a simulator. After you do this, look at how your NEXT is implemented, and figure out some instructions that could be added to make NEXT more efficient --- this will be the biggest step toward efficiency, as NEXT is usually the major bottleneck.

Use the split stack I described elsewhere --- this is what ISYS Forth did, and I did too in my cross-compiler --- this is a huge step forward in both speed and memory-efficiency.

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

#38594

On Friday, April 24, 2015 at 4:38:24 PM UTC-4, hughag...@gmail.com wrote:
> On Friday, April 24, 2015 at 12:22:16 PM UTC-7, Derek Simmons wrote:
> > On Wednesday, April 8, 2015 at 3:27:44 AM UTC-4, Jan Coombs wrote:
> > > On Mon, 23 Mar 2015 15:52:55 -0700 (PDT)
> > > Derek Simmons <dereks314@gmail.com> wrote:
> > > 
> > > > 
> > > > I'm looking for 4 or at least 1 R65F11. If anybody has stash or you know somebody I can contact I would be grateful.
> > > 
> > > If you don't get any chips, maybe there is an FPGA solution 
> > > for replacement hardware?  I'm about to start serious testing 
> > > of a CDP1802 system-on-chip, and the 6502 is not disimilar. 
> > > 
> > > BTW, sorry for helping with so much thread deviation...
> > > 
> > > Jan Coombs.
> > > -- 
> > > email valid, else fix dots and hyphen
> > > jan4clf2014@murrayhyphenmicroftdotcodotuk
> > 
> > You kind of hit the nail on the head. We are in kind of in a resource gathering phase. The first part is to get the Rockwell FORTH system working. The next phase would be to develop a FPGA based system. The long term goals is to replace the floppies with Flash memory cards, replace the software serial port with a hardware serial port, and the longest term goal is to replace the R6500 with an 65816 or similar. 
> > 
> > We've considered Jupiter Ace with GIDE but somebody already had done a lot of the work with the ZET project. we thought we were a head of the game by already having a FORTH development system.
> > 
> > In our circles we caught the attention of some professors. If we get a working FPGA system they would be interested in using for instructional purposes.
> 
> The 6502, 6511 and 65c02 were cool processors, but they had some design flaws. If you do make an FPGA that runs this machine-code, I recommend that you also add some new instructions that can be used by progressive 6502 programmers to avoid the problems of old.
> 
> For example, the 65c02 had a JMP indexed-indirect instruction, but it used X rather than Y. Any Forth programmer could have told the designers that Y should be used for the index because X is already being used as the data-stack pointer. Provide another similar instruction that uses Y, which will help to implement a byte-code Forth efficiently. A good byte-code Forth should provide extreme memory-efficiency --- this might actually make your processor useful in the real-world. 
> 
> It would be a good idea to write a byte-code Forth for the 65c02 first (using the new JMP instruction I described above), using a simulator. After you do this, look at how your NEXT is implemented, and figure out some instructions that could be added to make NEXT more efficient --- this will be the biggest step toward efficiency, as NEXT is usually the major bottleneck.
> 
> Use the split stack I described elsewhere --- this is what ISYS Forth did, and I did too in my cross-compiler --- this is a huge step forward in both speed and memory-efficiency.

We planned on reusing the core written for the C-1 but I'll keep your suggestions for improvements.

[toc] | [prev] | [standalone]

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

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

csiph-web