Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #28641 > unrolled thread
| Started by | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| First post | 2014-02-20 23:46 -0800 |
| Last post | 2014-02-21 10:55 -0800 |
| Articles | 4 — 2 participants |
Back to article view | Back to comp.lang.forth
tethered fpga Forth from Poland Paul Rubin <no.email@nospam.invalid> - 2014-02-20 23:46 -0800
Re: tethered fpga Forth from Poland forthisit@gmail.com - 2014-02-21 07:31 -0800
Re: tethered fpga Forth from Poland Paul Rubin <no.email@nospam.invalid> - 2014-02-21 10:28 -0800
Re: tethered fpga Forth from Poland forthisit@gmail.com - 2014-02-21 10:55 -0800
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-02-20 23:46 -0800 |
| Subject | tethered fpga Forth from Poland |
| Message-ID | <7xios8oqlq.fsf@ruckus.brouhaha.com> |
This looks interesting. They implemented a MISC-like softcore cpu as a diagnostic tool for other stuff running on an FPGA, driven by an interactive host-side Forth compiler written in Python and communicating with the FPGA target. http://www.ise.pw.edu.pl/~rrom/SPIE/SPIE8903-WILGA2013/8903/CD/WI13/DATA/8903_30.PDF
[toc] | [next] | [standalone]
| From | forthisit@gmail.com |
|---|---|
| Date | 2014-02-21 07:31 -0800 |
| Message-ID | <7147b831-dee2-4829-8057-b2e267ac9b37@googlegroups.com> |
| In reply to | #28641 |
On Friday, February 21, 2014 1:46:25 AM UTC-6, Paul Rubin wrote: > This looks interesting. They implemented a MISC-like softcore cpu as a > diagnostic tool for other stuff running on an FPGA, driven by an > interactive host-side Forth compiler written in Python and communicating > with the FPGA target. > > http://www.ise.pw.edu.pl/~rrom/SPIE/SPIE8903-WILGA2013/8903/CD/WI13/DATA/8903_30.PDF Thanks for posting this. This is exactly the application area that I think will contribute the most to keeping Forth out of "oblivion". However, I don't understand their rationale for dismissing the j1 for the role of target CPU. It's an efficient, fast, soft-core CPU that also happens to be stack-based with an instruction format that directly maps to primitive Forth words. What's not to like?
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-02-21 10:28 -0800 |
| Message-ID | <7x61o8tj5k.fsf@ruckus.brouhaha.com> |
| In reply to | #28660 |
forthisit@gmail.com writes:
> However, I don't understand their rationale for dismissing the j1 for
> the role of target CPU. It's an efficient, fast, soft-core CPU that
> also happens to be stack-based with an instruction format that
> directly maps to primitive Forth words. What's not to like?
From page 2 of the paper:
J1 is a very interesting solution, however from our point of view it
has one significant disadvantage -- it doesn't offer possibility of
interactive work. The program for J1 must be written and compiled in
advance, and put into the program memory located in internal RAM in
FPGA.
I notice they don't mention the B16 though.
[toc] | [prev] | [next] | [standalone]
| From | forthisit@gmail.com |
|---|---|
| Date | 2014-02-21 10:55 -0800 |
| Message-ID | <e8798fde-c0be-4502-b17d-afcb6460a41b@googlegroups.com> |
| In reply to | #28664 |
On Friday, February 21, 2014 12:28:23 PM UTC-6, Paul Rubin wrote: > forthisit@gmail.com writes: > > However, I don't understand their rationale for dismissing the j1 for > > the role of target CPU. It's an efficient, fast, soft-core CPU that > > also happens to be stack-based with an instruction format that > > directly maps to primitive Forth words. What's not to like? > > From page 2 of the paper: > > J1 is a very interesting solution, however from our point of view it > has one significant disadvantage -- it doesn't offer possibility of > interactive work. The program for J1 must be written and compiled in > advance, and put into the program memory located in internal RAM in > FPGA. > > I notice they don't mention the B16 though. I know. But what would make them think the J1 soft-core doesn't offer the possibility of interactive work, while an ARM soft-core does? (I have used the J1 for interactive work.) I can only guess that they didn't think the J1 was compatible with their EXEC_PC instruction somehow. From page 5 of the paper: The CPU is a small 16-bit processor. It offers instruction set suited for execution of Forth language (see Table 1). To support the tethered model, the CPU has special instruction (EXEC_PC) to execute operator in the host part of the system. The CPU is implemented according to the MISC (Minimal Instruction Set Architecture) paradigm - only the necessary instructions are supported, and more complex actions are implemented as Forth words. CPU executes instructions compiled and stored in the internal FPGA RAM memory. Regardless of the CPU used in the target, it's going to be running code out of the "internal FPGA RAM memory". What prevents that code from being interactive in the case of the J1? I must be missing something.
[toc] | [prev] | [standalone]
Back to top | Article view | comp.lang.forth
csiph-web