Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #59883 > unrolled thread
| Started by | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| First post | 2017-05-26 14:49 -0500 |
| Last post | 2017-05-28 21:38 -0700 |
| Articles | 20 on this page of 105 — 16 participants |
Back to article view | Back to comp.lang.forth
Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 14:49 -0500
Re: Forth Implementations advantages and disadvantages. minforth@arcor.de - 2017-05-26 13:17 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 17:53 -0500
Re: Forth Implementations advantages and disadvantages. Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 22:31 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 00:57 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 01:09 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 00:59 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 02:09 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 09:35 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 12:22 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 11:53 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 13:13 -0400
Re: Forth Implementations advantages and disadvantages. David Schultz <abuse@127.0.0.1> - 2017-05-27 12:24 -0500
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 13:13 -0500
Re: Forth Implementations advantages and disadvantages. David Schultz <abuse@127.0.0.1> - 2017-05-27 13:33 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 14:53 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 14:44 -0500
Re: Forth Implementations advantages and disadvantages. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 10:09 +0200
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-28 12:57 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 12:14 -0500
Re: Forth Implementations advantages and disadvantages. Paul Rubin <no.email@nospam.invalid> - 2017-05-28 16:11 -0700
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-29 02:11 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 01:54 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-29 03:22 -0400
Re: Forth Implementations advantages and disadvantages. Joel Rees <joel.rees@gmail.com> - 2017-05-28 15:46 -0700
Re: Forth Implementations advantages and disadvantages. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-27 01:23 -0500
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 09:29 -0500
Re: Forth Implementations advantages and disadvantages. Paul Rubin <no.email@nospam.invalid> - 2017-05-27 11:36 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 14:25 -0500
Re: Forth Implementations advantages and disadvantages. Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-05-27 21:58 -0400
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-27 11:20 -0700
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 15:20 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 14:20 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 18:33 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 18:50 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 20:13 -0400
Re: Forth Implementations advantages and disadvantages. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 10:23 +0200
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 12:26 -0500
Re: Forth Implementations advantages and disadvantages. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-30 04:22 -0500
Re: Forth Implementations advantages and disadvantages. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-30 11:49 +0200
Re: Forth Implementations advantages and disadvantages. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-30 05:07 -0500
Re: Forth Implementations advantages and disadvantages. Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-30 18:58 +0200
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 12:28 -0500
Re: Forth Implementations advantages and disadvantages. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 20:14 +0200
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 14:08 -0500
Re: Forth Implementations advantages and disadvantages. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-29 10:52 +0200
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 12:50 -0500
Re: Forth Implementations advantages and disadvantages. Alex <alex@rivadpm.com> - 2017-05-29 19:06 +0100
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-27 20:00 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 22:29 -0500
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-27 22:10 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 11:22 -0500
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-28 14:45 -0700
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-28 18:25 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 21:43 -0500
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-06-01 11:27 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-06-01 12:50 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-06-01 12:47 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-06-01 16:23 -0400
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-06-01 16:32 -0400
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-06-01 12:08 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-06-01 21:47 -0500
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-06-02 06:34 -0700
Re: Forth Implementations advantages and disadvantages. foxaudioresearch@gmail.com - 2017-06-02 07:13 -0700
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-06-02 07:57 -0700
Re: Forth Implementations advantages and disadvantages. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-03 02:17 +0200
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 21:07 -0500
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-28 21:48 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 00:52 -0500
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-29 09:17 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 12:16 -0500
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-29 19:21 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 23:13 -0500
Re: Forth Implementations advantages and disadvantages. Paul Rubin <no.email@nospam.invalid> - 2017-05-30 01:07 -0700
Re: Forth Implementations advantages and disadvantages. Alex <alex@rivadpm.com> - 2017-05-30 15:54 +0100
Re: Forth Implementations advantages and disadvantages. Alex <alex@rivadpm.com> - 2017-05-29 19:02 +0100
Re: Forth Implementations advantages and disadvantages. Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-29 11:06 -0700
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-29 19:29 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 23:01 -0500
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-30 14:53 -0700
Re: Forth Implementations advantages and disadvantages. Paul Rubin <no.email@nospam.invalid> - 2017-05-29 13:59 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 17:03 -0500
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-29 19:37 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 22:52 -0500
Re: Forth Implementations advantages and disadvantages. Mark Wills <markwills1970@gmail.com> - 2017-05-28 11:49 -0700
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 14:12 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-29 02:35 -0400
Re: Forth Implementations advantages and disadvantages. jim.brakefield@ieee.org - 2017-05-27 21:04 -0700
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-27 21:56 -0700
Re: Forth Implementations advantages and disadvantages. jim.brakefield@ieee.org - 2017-05-28 01:10 -0700
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-28 13:21 -0400
Re: Forth Implementations advantages and disadvantages. jim.brakefield@ieee.org - 2017-05-28 11:53 -0700
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-28 15:09 -0700
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-29 02:40 -0400
Re: Forth Implementations advantages and disadvantages. jim.brakefield@ieee.org - 2017-05-29 13:10 -0700
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-30 00:57 -0400
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-28 02:17 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 11:50 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-28 13:52 -0400
Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 13:47 -0500
Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-29 03:19 -0400
Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-28 15:40 -0700
Re: Forth Implementations advantages and disadvantages. Joel Rees <joel.rees@gmail.com> - 2017-05-28 16:31 -0700
Re: Forth Implementations advantages and disadvantages. Joel Rees <joel.rees@gmail.com> - 2017-05-28 20:17 -0700
Opinions on a C language header for words? Joel Rees <joel.rees@gmail.com> - 2017-05-28 21:38 -0700
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-30 05:07 -0500 |
| Message-ID | <9qGdncVlXOT22bDEnZ2dnUU7-bednZ2d@supernews.com> |
| In reply to | #60055 |
Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote: >> >>Microsoft's very own CLR depends on the ability to generate code on >>the fly and to patch it as it runs, so this ability is not going away >>any time soon. Plenty of other language runtimes (Java, Javascript, >>etc.) need to do this too. > > I'm presenting ciforth to Debian. They are definitely a bit upset > to see a program that has one section that is readable, writable and > executable. Is that really necessary? I would have thought to you allocate that at startup. > Tools get upset too. ( In wheezy `strip' strips lina to nothing.) Wow. Either that's a serious bug or there is something very wrong with the lina binary. One way or other it must be a bug. > In one of the reactions it was mentioned that googles `go' does > something similar, so that wouldn't not block admission of ciforth > as a Debian package. Indeed not. Really, this anti-JIT attitude from the OS distros is getting to be tiresome. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-05-30 18:58 +0200 |
| Message-ID | <86mv9umgdi.fsf@molnjunk.nocrew.org> |
| In reply to | #60056 |
Andrew Haley wrote:
> Albert van der Horst wrote:
>> Tools get upset too. ( In wheezy `strip' strips lina to nothing.)
>
> Wow. Either that's a serious bug or there is something very wrong
> with the lina binary.
Strip also does something damaging to my Forth image files. But I
suppose I have myself to blame. Here's what readelf -a says:
[ELF Header looks ok]
There are no sections in this file.
There are no sections to group in this file.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x08048000 0x08048000 0x029e8 0x16468 RWE 0x1000
There is no dynamic section in this file.
There are no relocations in this file.
Dynamic symbol information is not available for displaying symbols.
No version information found in this file.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-28 12:28 -0500 |
| Message-ID | <ogf166$g4d$2@dont-email.me> |
| In reply to | #59967 |
On 5/28/2017 3:23 AM, Albert van der Horst wrote: > In article <ogcum7$r9t$2@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >> Cecil Bayona wrote on 5/27/2017 3:20 PM: > <SNIP> >> >> I'm not sure what advantage "portable" assembly language would have over a >> metacompiled Forth. Both approaches require writing a back end for the >> tool. A metacompiled Forth has one HUGE advantage for developing a Forth >> system... it's in Forth. > > Truely "portable" or "high level" assembly is a pipe dream. > Using macro's to make assembly more portable surely is feasible. > ciforth may be a good example of that, using m4 a lot. How do you use m4 to create your Forth? Is it used as an external program to Forth or as a tools used separate from Forth? > > I can turn my indirect threaded Forth ciforth into a direct threaded Forth > rather easily, while Forth in c is probably subroutine threaded. > (At first sight I would think it infeasible to make an indirect threaded > Forth in c but apparently gforth has a threaded version.) > >> >> -- >> >> Rick C > > Groetjes Albert > -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-28 20:14 +0200 |
| Message-ID | <ogf42g$q8l$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #59979 |
In article <ogf166$g4d$2@dont-email.me>, Cecil Bayona <cbayona@cbayona.com> wrote: >On 5/28/2017 3:23 AM, Albert van der Horst wrote: >> In article <ogcum7$r9t$2@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >>> Cecil Bayona wrote on 5/27/2017 3:20 PM: >> <SNIP> >>> >>> I'm not sure what advantage "portable" assembly language would have over a >>> metacompiled Forth. Both approaches require writing a back end for the >>> tool. A metacompiled Forth has one HUGE advantage for developing a Forth >>> system... it's in Forth. >> >> Truely "portable" or "high level" assembly is a pipe dream. >> Using macro's to make assembly more portable surely is feasible. >> ciforth may be a good example of that, using m4 a lot. > >How do you use m4 to create your Forth? Is it used as an external >program to Forth or as a tools used separate from Forth? A rather short document (20 pages) contains about 10 pages relevant to this question. cifgenps.zip on the site in my sig. That document is from 2002. It could use an update but it surely gives the correct idea. I.a. I use it for selection (a la [IF] ) and as regular assembler macro's. > >> >> I can turn my indirect threaded Forth ciforth into a direct threaded Forth >> rather easily, while Forth in c is probably subroutine threaded. >> (At first sight I would think it infeasible to make an indirect threaded >> Forth in c but apparently gforth has a threaded version.) >> >>> >>> -- >>> >>> Rick C >> >> Groetjes Albert >> > > >-- >Cecil - k5nwa -- 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]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-28 14:08 -0500 |
| Message-ID | <ogf71j$5g4$1@dont-email.me> |
| In reply to | #59982 |
On 5/28/2017 1:14 PM, Albert van der Horst wrote: > In article <ogf166$g4d$2@dont-email.me>, > Cecil Bayona <cbayona@cbayona.com> wrote: >> On 5/28/2017 3:23 AM, Albert van der Horst wrote: >>> In article <ogcum7$r9t$2@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >>>> Cecil Bayona wrote on 5/27/2017 3:20 PM: >>> <SNIP> >>>> >>>> I'm not sure what advantage "portable" assembly language would have over a >>>> metacompiled Forth. Both approaches require writing a back end for the >>>> tool. A metacompiled Forth has one HUGE advantage for developing a Forth >>>> system... it's in Forth. >>> >>> Truely "portable" or "high level" assembly is a pipe dream. >>> Using macro's to make assembly more portable surely is feasible. >>> ciforth may be a good example of that, using m4 a lot. >> >> How do you use m4 to create your Forth? Is it used as an external >> program to Forth or as a tools used separate from Forth? > > A rather short document (20 pages) contains about 10 pages > relevant to this question. cifgenps.zip on the site in my sig. > That document is from 2002. It could use an update but it surely > gives the correct idea. > I.a. I use it for selection (a la [IF] ) and as regular > assembler macro's. You have a lot of links on your site so I was not able to find the link to the file. I found it with Google but it's in Postscript so I will need to find a reader. > >> >>> >>> I can turn my indirect threaded Forth ciforth into a direct threaded Forth >>> rather easily, while Forth in c is probably subroutine threaded. >>> (At first sight I would think it infeasible to make an indirect threaded >>> Forth in c but apparently gforth has a threaded version.) >>> >>>> >>>> -- >>>> >>>> Rick C >>> >>> Groetjes Albert >>> >> >> >> -- >> Cecil - k5nwa -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-29 10:52 +0200 |
| Message-ID | <oggnge$1mr$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #59986 |
In article <ogf71j$5g4$1@dont-email.me>,
Cecil Bayona <cbayona@cbayona.com> wrote:
<SNIP>
<question about the basic approach regards macro's of ciforth>
>> A rather short document (20 pages) contains about 10 pages
>> relevant to this question. cifgenps.zip on the site in my sig.
>> That document is from 2002. It could use an update but it surely
>> gives the correct idea.
>> I.a. I use it for selection (a la [IF] ) and as regular
>> assembler macro's.
>
>You have a lot of links on your site so I was not able to find the link
>to the file. I found it with Google but it's in Postscript so I will
>need to find a reader.
In my Debian Wheezy I need just click on a ps file. I'm not aware that
I needed to install anything.
gv is the official tool for postscript. That surely works.
For a quick look, go to github.com, search for ciforth and look at the
latest version in its unformatted source file (approximate texinfo)
cifgen.mi
If you get ciforth from github your can have the file converted to
pdf or info:
make cifgen.info cifgen.ps cifgen.pdf
Groetjes Albert
>--
>Cecil - k5nwa
--
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]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-29 12:50 -0500 |
| Message-ID | <oghmrb$rlj$1@dont-email.me> |
| In reply to | #60015 |
On 5/29/2017 3:52 AM, Albert van der Horst wrote: > In article <ogf71j$5g4$1@dont-email.me>, > Cecil Bayona <cbayona@cbayona.com> wrote: > <SNIP> > > <question about the basic approach regards macro's of ciforth> > >>> A rather short document (20 pages) contains about 10 pages >>> relevant to this question. cifgenps.zip on the site in my sig. >>> That document is from 2002. It could use an update but it surely >>> gives the correct idea. >>> I.a. I use it for selection (a la [IF] ) and as regular >>> assembler macro's. >> >> You have a lot of links on your site so I was not able to find the link >> to the file. I found it with Google but it's in Postscript so I will >> need to find a reader. > > In my Debian Wheezy I need just click on a ps file. I'm not aware that > I needed to install anything. > gv is the official tool for postscript. That surely works. > > For a quick look, go to github.com, search for ciforth and look at the > latest version in its unformatted source file (approximate texinfo) > cifgen.mi > > If you get ciforth from github your can have the file converted to > pdf or info: > make cifgen.info cifgen.ps cifgen.pdf > > Groetjes Albert > >> -- >> Cecil - k5nwa You are running Linux, I am running Windows which doesn't have a PostScript viewer built in like Linux does. Actually Linux has a lot more tools built in when compared to Windows yet Linux is a lot smaller that says a lot. Right now I'm thinking about switching to Linux so I'm building a fast PC with Linux Mint on it to give Linux a thorough test. The one thing that keeps holding me back is the money I spent on Windows Licenses and software, I have a lot of PCs so I hate to waste that money. But at some point I will be aggravated with Windows enough to dump it on most PCs. Anyway I installed a viewer and looked at the document, so you are using M4 as a tool to create a special version of ciforth according to ones desire. I have used macro processors in the past for a different purpose and that is to translate software from on language to another, and to take existing assembler code and optimize it. My oldest macro processor was capable enough that I wrote a Forth Cross Compiler with it which generated optimized assembler code. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-29 19:06 +0100 |
| Message-ID | <oghnpb$v23$1@dont-email.me> |
| In reply to | #60021 |
On 5/29/2017 18:50, Cecil Bayona wrote: > You are running Linux, I am running Windows which doesn't have a > PostScript viewer built in like Linux does. Actually Linux has a lot > more tools built in when compared to Windows yet Linux is a lot smaller > that says a lot. Windows 10 Edge provides the default PDF viewer; it's part of the distribution (built in in your parlance). -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-27 20:00 -0700 |
| Message-ID | <62e10459-9520-4e7b-b378-cff16e351fa7@googlegroups.com> |
| In reply to | #59945 |
On Saturday, May 27, 2017 at 12:20:48 PM UTC-7, Cecil - k5nwa wrote: > I'm not sure that using a limited MSP430 instruction set is the way to > go, it has a very nice instruction set but maybe a Portable Instruction > Set that has some added primitive like instructions might be a better > choice or a combination of the two. One way to find out is to test some > examples by using a decent Macro Assembler to generate the code and see > what is useful and what is not needed. > > I have some pretty decent Macro Processor software that is extremely > capable of manipulating text and do all sorts of translation, maybe it's > time to dig it out and see how good is a Portable Assembler and how > efficient it is at generating efficient code for multiple CPUs. Well, it should be a 16-bit processor. In the 32-bit world, ARM assembly-language already is the "portable assembly language" because 99% of the boards use an ARM processor. I just said the MSP430 because it is a common 16-bit processor. What application program do you have in mind? Is there some reason why the MSP430 wouldn't be a good choice for building a board? The PDP11 would be another possibility. It has these points in favor of it: 1.) the PDP11 has 8 registers rather than 16, which makes it a good choice for an FPGA (the number of registers is the primary factor in how much chip resources are needed, and how expensive the FPGA is). 2.) There are public-domain implementations of the PDP11 available in Verilog, which is not true of the MSP430. 3.) The PDP11 has a very orthogonal and straight-forward instruction set, which is not true of the 8086, although it is true of the MSP430.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-27 22:29 -0500 |
| Message-ID | <ogdg19$6tj$1@dont-email.me> |
| In reply to | #59955 |
On 5/27/2017 10:00 PM, hughaguilar96@gmail.com wrote: > On Saturday, May 27, 2017 at 12:20:48 PM UTC-7, Cecil - k5nwa wrote: >> I'm not sure that using a limited MSP430 instruction set is the way to >> go, it has a very nice instruction set but maybe a Portable Instruction >> Set that has some added primitive like instructions might be a better >> choice or a combination of the two. One way to find out is to test some >> examples by using a decent Macro Assembler to generate the code and see >> what is useful and what is not needed. >> >> I have some pretty decent Macro Processor software that is extremely >> capable of manipulating text and do all sorts of translation, maybe it's >> time to dig it out and see how good is a Portable Assembler and how >> efficient it is at generating efficient code for multiple CPUs. > > Well, it should be a 16-bit processor. In the 32-bit world, ARM assembly-language already is the "portable assembly language" because 99% of the boards use an ARM processor. > > I just said the MSP430 because it is a common 16-bit processor. What application program do you have in mind? Is there some reason why the MSP430 wouldn't be a good choice for building a board? > > The PDP11 would be another possibility. It has these points in favor of it: > > 1.) the PDP11 has 8 registers rather than 16, which makes it a good choice for an FPGA (the number of registers is the primary factor in how much chip resources are needed, and how expensive the FPGA is). > > 2.) There are public-domain implementations of the PDP11 available in Verilog, which is not true of the MSP430. > > 3.) The PDP11 has a very orthogonal and straight-forward instruction set, which is not true of the 8086, although it is true of the MSP430. > 16 bit is fine, the MSP430 is a very nice processor to program in assembler. I was just thinking out loud, it might not hurt to have some extra words that are Forth generic. The PDP11 is very nice for it's day but compared to modern CPUs it is register starved, I'm mostly interested in Forth CPUs and there are a few available, some are very simple such as the J1 CPU but with minor changes it can be improved but then I would need software that works with it hence the reason why this software is needed. I'll send you an email tomorrow or a modification to the assembler and get feedback on it. Big thunderstorm rolling through so I will need to turn the PC of for a while. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-27 22:10 -0700 |
| Message-ID | <76d52560-abac-4a83-a208-f63355f8852e@googlegroups.com> |
| In reply to | #59956 |
On Saturday, May 27, 2017 at 8:30:04 PM UTC-7, Cecil - k5nwa wrote: > The PDP11 is very nice for it's day but compared to modern CPUs it is > register starved, I'm mostly interested in Forth CPUs and there are a > few available, some are very simple such as the J1 CPU but with minor > changes it can be improved but then I would need software that works > with it hence the reason why this software is needed. I don't think the J1 supports local variables --- you are going to get Forth code that looks like it was written in the 1970s --- Forth code that passes data between functions in global variables is terrible; you would be better off to forget about Forth and use C instead. I just came up with this for a PDP11 STC off the top of my head, but it seems like it might work: R0 general-purpose R1 general-purpose R2 top-of-stack R3 local-frame pointer R4 data-stack pointer R5 double-stack pointer R6 return-stack pointer R7 program counter An optimizing compiler could take advantage of 16 registers, such as available on the MSP430 --- but are you planning on writing an optimizing compiler? --- that does take a lot of effort, and if you don't believe me, then ask Stephen Pelc. The JSR in the PDP11 would work very well for DTC. If you are going with STC however, you can simplify JSR so that it would be simple like on the MSP430 etc..
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-28 11:22 -0500 |
| Message-ID | <ogetaf$3jc$1@dont-email.me> |
| In reply to | #59960 |
On 5/28/2017 12:10 AM, hughaguilar96@gmail.com wrote: > On Saturday, May 27, 2017 at 8:30:04 PM UTC-7, Cecil - k5nwa wrote: >> The PDP11 is very nice for it's day but compared to modern CPUs it is >> register starved, I'm mostly interested in Forth CPUs and there are a >> few available, some are very simple such as the J1 CPU but with minor >> changes it can be improved but then I would need software that works >> with it hence the reason why this software is needed. > > I don't think the J1 supports local variables --- you are going to get Forth code that looks like it was written in the 1970s --- Forth code that passes data between functions in global variables is terrible; you would be better off to forget about Forth and use C instead. The J1 is a stack CPU so why would one pass data in global variables? One would use the Data Stack with Forth. > > I just came up with this for a PDP11 STC off the top of my head, but it seems like it might work: > > R0 general-purpose > R1 general-purpose > R2 top-of-stack > R3 local-frame pointer > R4 data-stack pointer > R5 double-stack pointer > R6 return-stack pointer > R7 program counter > > An optimizing compiler could take advantage of 16 registers, such as available on the MSP430 --- but are you planning on writing an optimizing compiler? --- that does take a lot of effort, and if you don't believe me, then ask Stephen Pelc. > The MSP430 is very similar to a PDP11 in it's architecture and faster for a couple of dollars, very nice. Having a Doubles Stack is very odd so it would create a lot of software compatibility issues but then Forthers are not famous for sharing software. What is the justification for such an odd item, does it really improve Forth? I would think if one is going to be odd and add an extra stack it might be more useful as a DO LOOP stack so the Data Stack and the Return Stack has no extra garbage making the code simpler. I have used in the past a very primitive but effective optimizing scheme that is easy to use and can generate very good code but it's a kludge at best. Using an external program to the compiler to do the optimizing, I mentioned the text macro processor before, it would be fed the code from each word and it would optimize it and generate assembler code that would be assembled in turn by the Forth compiler. Even the macro processor is a kludge itself, it was originally in FORTRAN then I used it to translate itself into C code but done without a whole lot of optimizing so the generated code was a mess but it worked and I never bothered to go back and clean it up. I once converted it to Forth but it was not efficient so I don't even have a copy anymore. Code from the early 70s used to translate code into efficient code in 2017, what a joke, but it would work. I dug it up last night one of the few old software projects that I still have a copy, it's for DOS currently. Over the next couple of days I will familiarize myself with it and see what I can do with it as a quick test environment, in with Portable Assembler Code and out with native CPU instructions for various CPUs to determine what instructions should be in the Portable Assembler Code. This would be to judge how efficient could be done and what instructions are necessary to do a good job. I also have a copy of a Forth based Macro Processor, its newer and totally different and it seems not as powerful but that would be a mistake in assuming so, it can incorporate Forth code that is executed during it's translation so one could do just about anything with it. Either one of these old software programs could do very good optimization but and it's a big but that there is little to no documentation on how to use them so I will have to rely on my memory to figure them out. Later in my life I started writing good documentation with my software to avoid such problems. > The JSR in the PDP11 would work very well for DTC. If you are going with STC however, you can simplify JSR so that it would be simple like on the MSP430 etc.. > Thanks for reminding me about PAC (Portable Assembler Code), it changes the whole trajectory of the project, if PAC can generate efficient code then it would be an ideal setup for this and other projects. In any case it is bound to be faster than using C. Mind you the whole purpose of this software is to Meta-Compile an efficient as reasonably possible Forth compiler for a variety of CPUs so it would not be used on a daily basis, it's a tool to create tools. This is getting very interesting and looks like a fun project. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-28 14:45 -0700 |
| Message-ID | <f29ebb3b-e12c-4338-81ec-0039204ad3e3@googlegroups.com> |
| In reply to | #59973 |
On Sunday, May 28, 2017 at 9:22:57 AM UTC-7, Cecil - k5nwa wrote: > On 5/28/2017 12:10 AM, hughaguilar96@gmail.com wrote: > > On Saturday, May 27, 2017 at 8:30:04 PM UTC-7, Cecil - k5nwa wrote: > >> The PDP11 is very nice for it's day but compared to modern CPUs it is > >> register starved, I'm mostly interested in Forth CPUs and there are a > >> few available, some are very simple such as the J1 CPU but with minor > >> changes it can be improved but then I would need software that works > >> with it hence the reason why this software is needed. > > > > I don't think the J1 supports local variables --- you are going to get Forth code that looks like it was written in the 1970s --- Forth code that passes data between functions in global variables is terrible; you would be better off to forget about Forth and use C instead. > > The J1 is a stack CPU so why would one pass data in global variables? > One would use the Data Stack with Forth. The data-stack is pretty cumbersome when you have more than three items. You end up with a lot of stack-juggling words --- also, you use >R R> to get data off the data-stack and out of the way temporarily --- the result is horrendously complicated code, even for simple functions, and Forth becomes a nightmare to maintain (even by the original programmer himself). Forth programming doesn't have to be a brain-buster though! If you want to boggle your mind, you should solve Sudoku puzzles with a pen --- or play Go against me on KGS --- I enjoy creating hugely complex situations on the Go board that confuse the opponent and awe the spectators (this works about half the time; the other half of the time I confuse myself and amuse the spectators). There are three methods available to prevent Forth from becoming a brain-buster, and turning Forth into an elegant language: 1.) Use local variables. Any function that has more than three parameters is a candidate for local variables. You should never use ROLL but should always use local variables instead. 2.) Pack your data into a struct, then pass the pointer to the struct into the function as a parameter. Oftentimes when you have a function with a lot of parameters, the parameters are related to each other. For example, the X Y and Z coordinates of a point should not be passed in as separate parameters (if you have two points, that's 6 parameters), but should be packed into a struct of type PT and the pointer to the struct passed in (if you have two points, that's 2 parameters). 3.) Create a separate stack dedicated to a common data-type. In my STRING-STACK.4TH package, I provide a stack for strings. Your typical ANS-Forth programmer is not smart enough to understand the three methods mentioned above. Your typical ANS-Forth programmer will pass data between functions in global variables. This is why PAD was put in the ANS-Forth standard. This is why most ANS-Forth programs are littered with VARIABLE and VALUE words that are used for holding data temporarily, and the functions have various assumptions about which global variables they need set and which global variables they will set (even if these assumptions are documented, the program is still confusing and unreliable). > > I just came up with this for a PDP11 STC off the top of my head, but it seems like it might work: > > > > R0 general-purpose > > R1 general-purpose > > R2 top-of-stack > > R3 local-frame pointer > > R4 data-stack pointer > > R5 double-stack pointer > > R6 return-stack pointer > > R7 program counter > > Having a Doubles Stack is very odd so it would create a lot of software > compatibility issues but then Forthers are not famous for sharing > software. What is the justification for such an odd item, does it really > improve Forth? I am assuming that you want a good Forth system --- not ANS-Forth, which looks like something from the 1970s. One of the major flaws of ANS-Forth was that it has single-cell and double-cell data intermixed on the data-stack (it even allows floats on the data-stack, although everybody ignores that and uses a separate float-stack). This is one of the reasons why ANS-Forth code is so badly infected with stack-juggling words and >R R> etc.. For example, if you have two doubles and a single on the data-stack, this is not three items (three would be manageable, as I said before) --- this is five items --- this is going to result in a hard-to-read mess. The mixed-precision arithmetic words will access both stacks. For example: S>D ( n -- ) \double: -- n M* ( a b -- ) \double: -- n FM/MOD ( divisor -- remainder quotient ) \double: numerator -- It is also possible to store strings on the double-stack as address/count pairs. Note that if you do this, then you can't have COW (copy-on-write) such as I have in STRING-STACK.4TH --- you have to copy the string to a new heap struct when you do DUP$ or OVER$ etc. --- in a micro-controller, you aren't likely working with strings very much though, so this inefficiency isn't a major problem. All in all, I think that a double-stack greatly improves Forth. There is no point in developing a new Forth unless it is going to be an improvement over ANS-Forth --- improving on ANS-Forth is easy and obvious --- this should always be done. > I would think if one is going to be odd and add an extra stack it might > be more useful as a DO LOOP stack so the Data Stack and the Return Stack > has no extra garbage making the code simpler. I wouldn't have DO LOOP at all. That is just cruft from the 1970s. You have local variables, so you should do iteration using BEGIN WHILE REPEAT and hold the index or whatever in local variables. The DO LOOP constructs use I and J as a crude kind of local variable --- this is not necessary if you have actual local variables available. Also, the application programmer shouldn't normally use BEGIN WHILE REPEAT at all. Code that does iteration using BEGIN WHILE REPEAT should be buried inside of HOFs, which are typically written by code-library writers or "systems programmers" or whatever. The application programmer would do iteration by writing a quotation and giving the quotation to a HOF that does the iteration internally and executes the quotation. I would expect that most programs would not have any explicit iteration with BEGIN WHILE REPEAT but would rely entirely on HOFs. > Thanks for reminding me about PAC (Portable Assembler Code), it changes > the whole trajectory of the project, if PAC can generate efficient code > then it would be an ideal setup for this and other projects. In any case > it is bound to be faster than using C. The PDP11 is the grandfather of all register-based processors (MC68000, PIC24, MSP430, etc.). If your assembler is for the PDP11, it can easily be retargeted to to any of these other processors, as all of them are supersets of the PDP11. You can also retarget it to processors such as the 6812 that have a shortage of registers (are a subset of the PDP11), but in this case some of the PDP11 registers will have to be implemented as pseudo-registers in memory --- this is going to be pretty inefficient, but at least you get portability --- these processors are obsolete nowadays, so nobody is likely to want to use them anyway. The MSP430 has 16 registers total. I would still use the PDP11 as your assembly-language as I described above. You can, however, have the main-program use some of the registers, and ISRs use the other registers. This means that ISRs don't have to save and restore registers (assuming that ISRs can't be interrupted). This should boost the speed of your system considerably, as a lot of micro-controller programs spend up to 50% of their time servicing interrupts. You will have to write your compiler in such a way that it is able to use the correct set of registers as R0..R7 depending upon whether it is compiling a colon word to be used in the main-program or is compiling an ISR. This should be easy. Put the functions that can be used by the main-program in one vocabulary and the functions that can be used by ISRs in another vocabulary, so there is no confusion if they have the same names. I think you are totally messing up the efficiency of your Forth system by assuming that you have 16 registers and your Forth should use them all. As I said, an optimizing compiler can make use of extra registers to hold values temporarily, but writing such an optimizing compiler is very difficult (I've never done it, and I wouldn't know how to even begin such a project). A much better use of 16 registers is to have two banks of 8 registers, which are used by the main-program and the ISRs. This is a micro-controller, after all --- most micro-controllers spend significant amounts of time saving and restoring registers as they enter and exit ISRs --- making ISRs efficient is the obvious way to boost the speed, and a lot easier than writing an optimizing compiler. Anyway --- my way of thinking about Forth is totally alien to that of the ANS-Forth and Forth-200x folks --- they are going to continue to use gForth (written in C) on the ARM under Linux (also written in C) and describe this as a "Forth micro-controller."
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-28 18:25 -0700 |
| Message-ID | <930cc033-885e-4a45-945e-f202af41f0b5@googlegroups.com> |
| In reply to | #59988 |
On Sunday, May 28, 2017 at 2:45:19 PM UTC-7, hughag...@gmail.com wrote: > On Sunday, May 28, 2017 at 9:22:57 AM UTC-7, Cecil - k5nwa wrote: > > On 5/28/2017 12:10 AM, hughaguilar96@gmail.com wrote: > > > I just came up with this for a PDP11 STC off the top of my head, but it seems like it might work: > > > > > > R0 general-purpose > > > R1 general-purpose > > > R2 top-of-stack > > > R3 local-frame pointer > > > R4 data-stack pointer > > > R5 double-stack pointer > > > R6 return-stack pointer > > > R7 program counter > > ... > > Thanks for reminding me about PAC (Portable Assembler Code), it changes > > the whole trajectory of the project, if PAC can generate efficient code > > then it would be an ideal setup for this and other projects. In any case > > it is bound to be faster than using C. > ... > The MSP430 has 16 registers total. I would still use the PDP11 as your assembly-language as I described above. You can, however, have the main-program use some of the registers, and ISRs use the other registers. This means that ISRs don't have to save and restore registers (assuming that ISRs can't be interrupted). This should boost the speed of your system considerably, as a lot of micro-controller programs spend up to 50% of their time servicing interrupts. You will have to write your compiler in such a way that it is able to use the correct set of registers as R0..R7 depending upon whether it is compiling a colon word to be used in the main-program or is compiling an ISR. This should be easy. Put the functions that can be used by the main-program in one vocabulary and the functions that can be used by ISRs in another vocabulary, so there is no confusion if they have the same names. The more that I think about it, the more I like the PDP11 as your portable-assembly-language. 1.) The 8 registers of the PDP11 are adequate for a reasonable Forth implementation (as shown above in the register-dedication table I provided). You do have two general-purpose registers, so you can do code-optimization in which you hold values in general-purpose registers temporarily rather than push them to the data-stack (VFX does code optimization on the 32-bit x86 that has only one more register than the PDP11 has). 2.) On modern processors that have 16 registers (such as the MSP430), you can divide the registers into two banks for the main-program and the ISRs to significantly speed up ISRs while still allowing ISRs to be written in Forth. Your ISRs can't be interrupted though, because there is only one bank of registers available. On the PIC24 you can also have fast ISRs written in assembly-language that only use the lower four registers and are able to interrupt the lower-priority ISRs that are written in Forth. 3.) There are HDL implementations of the PDP11 already available, so if you want an FPGA you can use one of these as a starting point. Considering that you (and I) have little or no experience with HDL, it seems more realistic to start with an existing implementation rather than start from scratch. 4.) There is software available for the PDP11, such as RT11, that could still be useful. Your assembler should be compatible with whatever assembler was used to assemble the RT11 code, except that your assembler generates code for the MSP430, PIC24, etc.. So, if the source-code to RT11 is available (I assume it is), you could run RT11 on an MSP430 or PIC24 or whatever. It will be just like a George Romero movie: the dead will rise and walk again!
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-28 21:43 -0500 |
| Message-ID | <ogg1m5$h7u$1@dont-email.me> |
| In reply to | #59995 |
On 5/28/2017 8:25 PM, hughaguilar96@gmail.com wrote: > On Sunday, May 28, 2017 at 2:45:19 PM UTC-7, hughag...@gmail.com wrote: >> On Sunday, May 28, 2017 at 9:22:57 AM UTC-7, Cecil - k5nwa wrote: >> ... >> The MSP430 has 16 registers total. I would still use the PDP11 as your assembly-language as I described above. You can, however, have the main-program use some of the registers, and ISRs use the other registers. This means that ISRs don't have to save and restore registers (assuming that ISRs can't be interrupted). This should boost the speed of your system considerably, as a lot of micro-controller programs spend up to 50% of their time servicing interrupts. You will have to write your compiler in such a way that it is able to use the correct set of registers as R0..R7 depending upon whether it is compiling a colon word to be used in the main-program or is compiling an ISR. This should be easy. Put the functions that can be used by the main-program in one vocabulary and the functions that can be used by ISRs in another vocabulary, so there is no confusion if they have the same names. > > The more that I think about it, the more I like the PDP11 as your portable-assembly-language. A very nice processor to program in assembler and easy to generate code for in high level languages. The main modern CPUs that I would like to implement eventually are PIC32, PIC24, dsPIC, MSP430, and the W65C816, all of these with exception of the W65C816 have more than 8 registers Although I already have MPE VFX for the MSP430 and eForth for the same CPU so that would not be an immediate CPU to target. > 1.) The 8 registers of the PDP11 are adequate for a reasonable Forth implementation (as shown above in the register-dedication table I provided). You do have two general-purpose registers, so you can do code-optimization in which you hold values in general-purpose registers temporarily rather than push them to the data-stack (VFX does code optimization on the 32-bit x86 that has only one more register than the PDP11 has). > > 2.) On modern processors that have 16 registers (such as the MSP430), you can divide the registers into two banks for the main-program and the ISRs to significantly speed up ISRs while still allowing ISRs to be written in Forth. Your ISRs can't be interrupted though, because there is only one bank of registers available. On the PIC24 you can also have fast ISRs written in assembly-language that only use the lower four registers and are able to interrupt the lower-priority ISRs that are written in Forth. > > 3.) There are HDL implementations of the PDP11 already available, so if you want an FPGA you can use one of these as a starting point. Considering that you (and I) have little or no experience with HDL, it seems more realistic to start with an existing implementation rather than start from scratch. > > 4.) There is software available for the PDP11, such as RT11, that could still be useful. Your assembler should be compatible with whatever assembler was used to assemble the RT11 code, except that your assembler generates code for the MSP430, PIC24, etc.. So, if the source-code to RT11 is available (I assume it is), you could run RT11 on an MSP430 or PIC24 or whatever. It will be just like a George Romero movie: the dead will rise and walk again! > I remember seeing some emulators available that ran RT11, good for testing purposes. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-06-01 11:27 -0500 |
| Message-ID | <ogpf3i$ea6$1@dont-email.me> |
| In reply to | #59995 |
On 5/28/2017 8:25 PM, hughaguilar96@gmail.com wrote: > On Sunday, May 28, 2017 at 2:45:19 PM UTC-7, hughag...@gmail.com wrote: >> On Sunday, May 28, 2017 at 9:22:57 AM UTC-7, Cecil - k5nwa wrote: >>> On 5/28/2017 12:10 AM, hughaguilar96@gmail.com wrote: >>>> I just came up with this for a PDP11 STC off the top of my head, but it seems like it might work: >>>> >>>> R0 general-purpose >>>> R1 general-purpose >>>> R2 top-of-stack >>>> R3 local-frame pointer >>>> R4 data-stack pointer >>>> R5 double-stack pointer >>>> R6 return-stack pointer >>>> R7 program counter >>> ... >>> Thanks for reminding me about PAC (Portable Assembler Code), it changes >>> the whole trajectory of the project, if PAC can generate efficient code >>> then it would be an ideal setup for this and other projects. In any case >>> it is bound to be faster than using C. >> ... >> The MSP430 has 16 registers total. I would still use the PDP11 as your assembly-language as I described above. You can, however, have the main-program use some of the registers, and ISRs use the other registers. This means that ISRs don't have to save and restore registers (assuming that ISRs can't be interrupted). This should boost the speed of your system considerably, as a lot of micro-controller programs spend up to 50% of their time servicing interrupts. You will have to write your compiler in such a way that it is able to use the correct set of registers as R0..R7 depending upon whether it is compiling a colon word to be used in the main-program or is compiling an ISR. This should be easy. Put the functions that can be used by the main-program in one vocabulary and the functions that can be used by ISRs in another vocabulary, so there is no confusion if they have the same names. > > The more that I think about it, the more I like the PDP11 as your portable-assembly-language. > > 1.) The 8 registers of the PDP11 are adequate for a reasonable Forth implementation (as shown above in the register-dedication table I provided). You do have two general-purpose registers, so you can do code-optimization in which you hold values in general-purpose registers temporarily rather than push them to the data-stack (VFX does code optimization on the 32-bit x86 that has only one more register than the PDP11 has). > > 2.) On modern processors that have 16 registers (such as the MSP430), you can divide the registers into two banks for the main-program and the ISRs to significantly speed up ISRs while still allowing ISRs to be written in Forth. Your ISRs can't be interrupted though, because there is only one bank of registers available. On the PIC24 you can also have fast ISRs written in assembly-language that only use the lower four registers and are able to interrupt the lower-priority ISRs that are written in Forth. > > 3.) There are HDL implementations of the PDP11 already available, so if you want an FPGA you can use one of these as a starting point. Considering that you (and I) have little or no experience with HDL, it seems more realistic to start with an existing implementation rather than start from scratch. > > 4.) There is software available for the PDP11, such as RT11, that could still be useful. Your assembler should be compatible with whatever assembler was used to assemble the RT11 code, except that your assembler generates code for the MSP430, PIC24, etc.. So, if the source-code to RT11 is available (I assume it is), you could run RT11 on an MSP430 or PIC24 or whatever. It will be just like a George Romero movie: the dead will rise and walk again! > I downloaded some PDP11 programming manuals and read them over several days and come to the conclusion the the PDP11 is not a good choice because is has features that a lot of modern 16 bit device do not possess mostly in the area of addressing modes, but also unique instructions. The process also impressed me why I used to love the PDP11 when I first started working with computers, my first computer I worked with was the PDP8e and the PDP11 was such a refreshing improvement, now the 64KB direct addressing limit is a pain. Right off the bat on the PDP11 all registers are equal so any register has all addressing modes, that is inefficient to implement in modern CPUs. The PDP11 also has independent addressing for each of two operands so for example an ADD instruction can have both sources to use indexed modes for the data for memory to memory operation while most modern CPUs uses a register as one of the sources/destination and the other one can be indexed but not both so in some cases it takes two instructions to do the same as one PDP11 instruction, not the end of the world but it makes things more complicated. So the choices are; 1, To map one instruction to many in some cases and use the PDP11 instruction set. 2. Use a more limited CPU like the MSP430 as a guide to the instructions instead. 3. Just invent my own mnemonics like the Go language that maps closely to existing CPUs. 4. Just plain create the primitives in native assembler like it's always been done. I still see an advantage to use a PAC (1-3) coding as a lot of code written in it is easily portable to other 16 bit CPUs. More reading and comparing is required so I will play some more with the PDP11 to modern CPU instruct instruction mapping to see how practical it all is. This whole project is getting more complicated and messy than anticipated, such is life. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-06-01 12:50 -0400 |
| Message-ID | <ogpge1$i5t$3@dont-email.me> |
| In reply to | #60151 |
Cecil Bayona wrote on 6/1/2017 12:27 PM: > On 5/28/2017 8:25 PM, hughaguilar96@gmail.com wrote: >> On Sunday, May 28, 2017 at 2:45:19 PM UTC-7, hughag...@gmail.com wrote: >>> On Sunday, May 28, 2017 at 9:22:57 AM UTC-7, Cecil - k5nwa wrote: >>>> On 5/28/2017 12:10 AM, hughaguilar96@gmail.com wrote: >>>>> I just came up with this for a PDP11 STC off the top of my head, but it >>>>> seems like it might work: >>>>> >>>>> R0 general-purpose >>>>> R1 general-purpose >>>>> R2 top-of-stack >>>>> R3 local-frame pointer >>>>> R4 data-stack pointer >>>>> R5 double-stack pointer >>>>> R6 return-stack pointer >>>>> R7 program counter >>>> ... >>>> Thanks for reminding me about PAC (Portable Assembler Code), it changes >>>> the whole trajectory of the project, if PAC can generate efficient code >>>> then it would be an ideal setup for this and other projects. In any case >>>> it is bound to be faster than using C. >>> ... >>> The MSP430 has 16 registers total. I would still use the PDP11 as your >>> assembly-language as I described above. You can, however, have the >>> main-program use some of the registers, and ISRs use the other registers. >>> This means that ISRs don't have to save and restore registers (assuming >>> that ISRs can't be interrupted). This should boost the speed of your >>> system considerably, as a lot of micro-controller programs spend up to >>> 50% of their time servicing interrupts. You will have to write your >>> compiler in such a way that it is able to use the correct set of >>> registers as R0..R7 depending upon whether it is compiling a colon word >>> to be used in the main-program or is compiling an ISR. This should be >>> easy. Put the functions that can be used by the main-program in one >>> vocabulary and the functions that can be used by ISRs in another >>> vocabulary, so there is no confusion if they have the same names. >> >> The more that I think about it, the more I like the PDP11 as your >> portable-assembly-language. >> >> 1.) The 8 registers of the PDP11 are adequate for a reasonable Forth >> implementation (as shown above in the register-dedication table I >> provided). You do have two general-purpose registers, so you can do >> code-optimization in which you hold values in general-purpose registers >> temporarily rather than push them to the data-stack (VFX does code >> optimization on the 32-bit x86 that has only one more register than the >> PDP11 has). >> >> 2.) On modern processors that have 16 registers (such as the MSP430), you >> can divide the registers into two banks for the main-program and the ISRs >> to significantly speed up ISRs while still allowing ISRs to be written in >> Forth. Your ISRs can't be interrupted though, because there is only one >> bank of registers available. On the PIC24 you can also have fast ISRs >> written in assembly-language that only use the lower four registers and >> are able to interrupt the lower-priority ISRs that are written in Forth. >> >> 3.) There are HDL implementations of the PDP11 already available, so if >> you want an FPGA you can use one of these as a starting point. Considering >> that you (and I) have little or no experience with HDL, it seems more >> realistic to start with an existing implementation rather than start from >> scratch. >> >> 4.) There is software available for the PDP11, such as RT11, that could >> still be useful. Your assembler should be compatible with whatever >> assembler was used to assemble the RT11 code, except that your assembler >> generates code for the MSP430, PIC24, etc.. So, if the source-code to RT11 >> is available (I assume it is), you could run RT11 on an MSP430 or PIC24 or >> whatever. It will be just like a George Romero movie: the dead will rise >> and walk again! >> > > I downloaded some PDP11 programming manuals and read them over several days > and come to the conclusion the the PDP11 is not a good choice because is has > features that a lot of modern 16 bit device do not possess mostly in the > area of addressing modes, but also unique instructions. > > The process also impressed me why I used to love the PDP11 when I first > started working with computers, my first computer I worked with was the > PDP8e and the PDP11 was such a refreshing improvement, now the 64KB direct > addressing limit is a pain. > > Right off the bat on the PDP11 all registers are equal so any register has > all addressing modes, that is inefficient to implement in modern CPUs. The > PDP11 also has independent addressing for each of two operands so for > example an ADD instruction can have both sources to use indexed modes for > the data for memory to memory operation while most modern CPUs uses a > register as one of the sources/destination and the other one can be indexed > but not both so in some cases it takes two instructions to do the same as > one PDP11 instruction, not the end of the world but it makes things more > complicated. > > So the choices are; > > 1, To map one instruction to many in some cases and use the PDP11 > instruction set. > 2. Use a more limited CPU like the MSP430 as a guide to the instructions > instead. > 3. Just invent my own mnemonics like the Go language that maps closely to > existing CPUs. How is this distinguished from writing words in Forth? > 4. Just plain create the primitives in native assembler like it's always > been done. > > I still see an advantage to use a PAC (1-3) coding as a lot of code written > in it is easily portable to other 16 bit CPUs. > > More reading and comparing is required so I will play some more with the > PDP11 to modern CPU instruct instruction mapping to see how practical it all > is. > > This whole project is getting more complicated and messy than anticipated, > such is life. What a surprise! -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-06-01 12:47 -0500 |
| Message-ID | <ogpjpd$mr$1@dont-email.me> |
| In reply to | #60155 |
On 6/1/2017 11:50 AM, rickman wrote: > Cecil Bayona wrote on 6/1/2017 12:27 PM: >> On 5/28/2017 8:25 PM, hughaguilar96@gmail.com wrote: >>> On Sunday, May 28, 2017 at 2:45:19 PM UTC-7, hughag...@gmail.com wrote: >>>> On Sunday, May 28, 2017 at 9:22:57 AM UTC-7, Cecil - k5nwa wrote: >>>>> On 5/28/2017 12:10 AM, hughaguilar96@gmail.com wrote: >>>>>> I just came up with this for a PDP11 STC off the top of my head, >>>>>> but it >>>>>> seems like it might work: >>>>>> >>>>>> R0 general-purpose >>>>>> R1 general-purpose >>>>>> R2 top-of-stack >>>>>> R3 local-frame pointer >>>>>> R4 data-stack pointer >>>>>> R5 double-stack pointer >>>>>> R6 return-stack pointer >>>>>> R7 program counter >>>>> ... >>>>> Thanks for reminding me about PAC (Portable Assembler Code), it >>>>> changes >>>>> the whole trajectory of the project, if PAC can generate efficient >>>>> code >>>>> then it would be an ideal setup for this and other projects. In any >>>>> case >>>>> it is bound to be faster than using C. >>>> ... >>>> The MSP430 has 16 registers total. I would still use the PDP11 as your >>>> assembly-language as I described above. You can, however, have the >>>> main-program use some of the registers, and ISRs use the other >>>> registers. >>>> This means that ISRs don't have to save and restore registers (assuming >>>> that ISRs can't be interrupted). This should boost the speed of your >>>> system considerably, as a lot of micro-controller programs spend up to >>>> 50% of their time servicing interrupts. You will have to write your >>>> compiler in such a way that it is able to use the correct set of >>>> registers as R0..R7 depending upon whether it is compiling a colon word >>>> to be used in the main-program or is compiling an ISR. This should be >>>> easy. Put the functions that can be used by the main-program in one >>>> vocabulary and the functions that can be used by ISRs in another >>>> vocabulary, so there is no confusion if they have the same names. >>> >>> The more that I think about it, the more I like the PDP11 as your >>> portable-assembly-language. >>> >>> 1.) The 8 registers of the PDP11 are adequate for a reasonable Forth >>> implementation (as shown above in the register-dedication table I >>> provided). You do have two general-purpose registers, so you can do >>> code-optimization in which you hold values in general-purpose registers >>> temporarily rather than push them to the data-stack (VFX does code >>> optimization on the 32-bit x86 that has only one more register than the >>> PDP11 has). >>> >>> 2.) On modern processors that have 16 registers (such as the MSP430), >>> you >>> can divide the registers into two banks for the main-program and the >>> ISRs >>> to significantly speed up ISRs while still allowing ISRs to be >>> written in >>> Forth. Your ISRs can't be interrupted though, because there is only one >>> bank of registers available. On the PIC24 you can also have fast ISRs >>> written in assembly-language that only use the lower four registers and >>> are able to interrupt the lower-priority ISRs that are written in Forth. >>> >>> 3.) There are HDL implementations of the PDP11 already available, so if >>> you want an FPGA you can use one of these as a starting point. >>> Considering >>> that you (and I) have little or no experience with HDL, it seems more >>> realistic to start with an existing implementation rather than start >>> from >>> scratch. >>> >>> 4.) There is software available for the PDP11, such as RT11, that could >>> still be useful. Your assembler should be compatible with whatever >>> assembler was used to assemble the RT11 code, except that your assembler >>> generates code for the MSP430, PIC24, etc.. So, if the source-code to >>> RT11 >>> is available (I assume it is), you could run RT11 on an MSP430 or >>> PIC24 or >>> whatever. It will be just like a George Romero movie: the dead will rise >>> and walk again! >>> >> >> I downloaded some PDP11 programming manuals and read them over several >> days >> and come to the conclusion the the PDP11 is not a good choice because >> is has >> features that a lot of modern 16 bit device do not possess mostly in the >> area of addressing modes, but also unique instructions. >> >> The process also impressed me why I used to love the PDP11 when I first >> started working with computers, my first computer I worked with was the >> PDP8e and the PDP11 was such a refreshing improvement, now the 64KB >> direct >> addressing limit is a pain. >> >> Right off the bat on the PDP11 all registers are equal so any >> register has >> all addressing modes, that is inefficient to implement in modern CPUs. >> The >> PDP11 also has independent addressing for each of two operands so for >> example an ADD instruction can have both sources to use indexed modes >> for >> the data for memory to memory operation while most modern CPUs uses a >> register as one of the sources/destination and the other one can be >> indexed >> but not both so in some cases it takes two instructions to do the same as >> one PDP11 instruction, not the end of the world but it makes things more >> complicated. >> >> So the choices are; >> >> 1, To map one instruction to many in some cases and use the PDP11 >> instruction set. >> 2. Use a more limited CPU like the MSP430 as a guide to the instructions >> instead. >> 3. Just invent my own mnemonics like the Go language that maps closely to >> existing CPUs. > > How is this distinguished from writing words in Forth? At some point the Forth is created by creating set of primitives word, one creates Forth primitives from assembler or High level language. Even a Meta compiler at some level needs words written in assembler. > > >> 4. Just plain create the primitives in native assembler like it's always >> been done. >> >> I still see an advantage to use a PAC (1-3) coding as a lot of code >> written >> in it is easily portable to other 16 bit CPUs. >> >> More reading and comparing is required so I will play some more with the >> PDP11 to modern CPU instruct instruction mapping to see how practical >> it all >> is. >> >> This whole project is getting more complicated and messy than >> anticipated, >> such is life. > > What a surprise! > Have you created your own Forth from scratch before? If you have not then having an assembler doesn't make any sense it's vital create a Forth written mostly in Forth. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-06-01 16:23 -0400 |
| Message-ID | <ogpsud$j66$1@dont-email.me> |
| In reply to | #60157 |
Cecil Bayona wrote on 6/1/2017 1:47 PM: > On 6/1/2017 11:50 AM, rickman wrote: >> Cecil Bayona wrote on 6/1/2017 12:27 PM: >>> On 5/28/2017 8:25 PM, hughaguilar96@gmail.com wrote: >>>> On Sunday, May 28, 2017 at 2:45:19 PM UTC-7, hughag...@gmail.com wrote: >>>>> On Sunday, May 28, 2017 at 9:22:57 AM UTC-7, Cecil - k5nwa wrote: >>>>>> On 5/28/2017 12:10 AM, hughaguilar96@gmail.com wrote: >>>>>>> I just came up with this for a PDP11 STC off the top of my head, but it >>>>>>> seems like it might work: >>>>>>> >>>>>>> R0 general-purpose >>>>>>> R1 general-purpose >>>>>>> R2 top-of-stack >>>>>>> R3 local-frame pointer >>>>>>> R4 data-stack pointer >>>>>>> R5 double-stack pointer >>>>>>> R6 return-stack pointer >>>>>>> R7 program counter >>>>>> ... >>>>>> Thanks for reminding me about PAC (Portable Assembler Code), it changes >>>>>> the whole trajectory of the project, if PAC can generate efficient code >>>>>> then it would be an ideal setup for this and other projects. In any case >>>>>> it is bound to be faster than using C. >>>>> ... >>>>> The MSP430 has 16 registers total. I would still use the PDP11 as your >>>>> assembly-language as I described above. You can, however, have the >>>>> main-program use some of the registers, and ISRs use the other registers. >>>>> This means that ISRs don't have to save and restore registers (assuming >>>>> that ISRs can't be interrupted). This should boost the speed of your >>>>> system considerably, as a lot of micro-controller programs spend up to >>>>> 50% of their time servicing interrupts. You will have to write your >>>>> compiler in such a way that it is able to use the correct set of >>>>> registers as R0..R7 depending upon whether it is compiling a colon word >>>>> to be used in the main-program or is compiling an ISR. This should be >>>>> easy. Put the functions that can be used by the main-program in one >>>>> vocabulary and the functions that can be used by ISRs in another >>>>> vocabulary, so there is no confusion if they have the same names. >>>> >>>> The more that I think about it, the more I like the PDP11 as your >>>> portable-assembly-language. >>>> >>>> 1.) The 8 registers of the PDP11 are adequate for a reasonable Forth >>>> implementation (as shown above in the register-dedication table I >>>> provided). You do have two general-purpose registers, so you can do >>>> code-optimization in which you hold values in general-purpose registers >>>> temporarily rather than push them to the data-stack (VFX does code >>>> optimization on the 32-bit x86 that has only one more register than the >>>> PDP11 has). >>>> >>>> 2.) On modern processors that have 16 registers (such as the MSP430), you >>>> can divide the registers into two banks for the main-program and the ISRs >>>> to significantly speed up ISRs while still allowing ISRs to be written in >>>> Forth. Your ISRs can't be interrupted though, because there is only one >>>> bank of registers available. On the PIC24 you can also have fast ISRs >>>> written in assembly-language that only use the lower four registers and >>>> are able to interrupt the lower-priority ISRs that are written in Forth. >>>> >>>> 3.) There are HDL implementations of the PDP11 already available, so if >>>> you want an FPGA you can use one of these as a starting point. Considering >>>> that you (and I) have little or no experience with HDL, it seems more >>>> realistic to start with an existing implementation rather than start from >>>> scratch. >>>> >>>> 4.) There is software available for the PDP11, such as RT11, that could >>>> still be useful. Your assembler should be compatible with whatever >>>> assembler was used to assemble the RT11 code, except that your assembler >>>> generates code for the MSP430, PIC24, etc.. So, if the source-code to RT11 >>>> is available (I assume it is), you could run RT11 on an MSP430 or PIC24 or >>>> whatever. It will be just like a George Romero movie: the dead will rise >>>> and walk again! >>>> >>> >>> I downloaded some PDP11 programming manuals and read them over several days >>> and come to the conclusion the the PDP11 is not a good choice because is has >>> features that a lot of modern 16 bit device do not possess mostly in the >>> area of addressing modes, but also unique instructions. >>> >>> The process also impressed me why I used to love the PDP11 when I first >>> started working with computers, my first computer I worked with was the >>> PDP8e and the PDP11 was such a refreshing improvement, now the 64KB direct >>> addressing limit is a pain. >>> >>> Right off the bat on the PDP11 all registers are equal so any register has >>> all addressing modes, that is inefficient to implement in modern CPUs. The >>> PDP11 also has independent addressing for each of two operands so for >>> example an ADD instruction can have both sources to use indexed modes for >>> the data for memory to memory operation while most modern CPUs uses a >>> register as one of the sources/destination and the other one can be indexed >>> but not both so in some cases it takes two instructions to do the same as >>> one PDP11 instruction, not the end of the world but it makes things more >>> complicated. >>> >>> So the choices are; >>> >>> 1, To map one instruction to many in some cases and use the PDP11 >>> instruction set. >>> 2. Use a more limited CPU like the MSP430 as a guide to the instructions >>> instead. >>> 3. Just invent my own mnemonics like the Go language that maps closely to >>> existing CPUs. >> >> How is this distinguished from writing words in Forth? > > At some point the Forth is created by creating set of primitives word, one > creates Forth primitives from assembler or High level language. Even a Meta > compiler at some level needs words written in assembler. You keep walking all around the point where you clearly see what is going on. I don't understand why you can't see it. Yes, some assembly will always be required. That is true for *EVERY* approach you define. Inventing an intermediate language that looks vaguely like an assembly language is no different than just writing a few core words in Forth. Both ways you have to write some code that generates code for your target machine. I think you have compartmentalized the various terms and given them specific meanings that don't let you see the fact that you are doing the same thing by different means with many of the same problems and advantages. >>> 4. Just plain create the primitives in native assembler like it's always >>> been done. >>> >>> I still see an advantage to use a PAC (1-3) coding as a lot of code written >>> in it is easily portable to other 16 bit CPUs. >>> >>> More reading and comparing is required so I will play some more with the >>> PDP11 to modern CPU instruct instruction mapping to see how practical it all >>> is. >>> >>> This whole project is getting more complicated and messy than anticipated, >>> such is life. >> >> What a surprise! >> > > Have you created your own Forth from scratch before? If you have not then > having an assembler doesn't make any sense it's vital create a Forth written > mostly in Forth. Something happened to your sentence structure so I don't know what you are trying to say. All I am saying is that writing base level code in a special language which is converted to machine code for your target offers no advantages over simply writing as much as possible in Forth and the rest in target specific assembly language. Either way you must write or modify the code which generate or expresses the target specific code. I don't see how it is any easier to rewrite the code generator for a target rather than rewriting a few Forth words written in assembly language. What it does accomplish is to obfuscate the operation of the code to a user. I would much prefer to dig through the *target* assembly language when trying to understand what is going on compared to having to dig through an assembly language that *isn't* for the target and then trying to figure out how that generated the code being executed. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-06-01 16:32 -0400 |
| Message-ID | <ogptec$j66$4@dont-email.me> |
| In reply to | #60162 |
rickman wrote on 6/1/2017 4:23 PM: > Cecil Bayona wrote on 6/1/2017 1:47 PM: >> On 6/1/2017 11:50 AM, rickman wrote: >>> Cecil Bayona wrote on 6/1/2017 12:27 PM: >>>> On 5/28/2017 8:25 PM, hughaguilar96@gmail.com wrote: >>>>> On Sunday, May 28, 2017 at 2:45:19 PM UTC-7, hughag...@gmail.com wrote: >>>>>> On Sunday, May 28, 2017 at 9:22:57 AM UTC-7, Cecil - k5nwa wrote: >>>>>>> On 5/28/2017 12:10 AM, hughaguilar96@gmail.com wrote: >>>>>>>> I just came up with this for a PDP11 STC off the top of my head, but it >>>>>>>> seems like it might work: >>>>>>>> >>>>>>>> R0 general-purpose >>>>>>>> R1 general-purpose >>>>>>>> R2 top-of-stack >>>>>>>> R3 local-frame pointer >>>>>>>> R4 data-stack pointer >>>>>>>> R5 double-stack pointer >>>>>>>> R6 return-stack pointer >>>>>>>> R7 program counter >>>>>>> ... >>>>>>> Thanks for reminding me about PAC (Portable Assembler Code), it changes >>>>>>> the whole trajectory of the project, if PAC can generate efficient code >>>>>>> then it would be an ideal setup for this and other projects. In any case >>>>>>> it is bound to be faster than using C. >>>>>> ... >>>>>> The MSP430 has 16 registers total. I would still use the PDP11 as your >>>>>> assembly-language as I described above. You can, however, have the >>>>>> main-program use some of the registers, and ISRs use the other registers. >>>>>> This means that ISRs don't have to save and restore registers (assuming >>>>>> that ISRs can't be interrupted). This should boost the speed of your >>>>>> system considerably, as a lot of micro-controller programs spend up to >>>>>> 50% of their time servicing interrupts. You will have to write your >>>>>> compiler in such a way that it is able to use the correct set of >>>>>> registers as R0..R7 depending upon whether it is compiling a colon word >>>>>> to be used in the main-program or is compiling an ISR. This should be >>>>>> easy. Put the functions that can be used by the main-program in one >>>>>> vocabulary and the functions that can be used by ISRs in another >>>>>> vocabulary, so there is no confusion if they have the same names. >>>>> >>>>> The more that I think about it, the more I like the PDP11 as your >>>>> portable-assembly-language. >>>>> >>>>> 1.) The 8 registers of the PDP11 are adequate for a reasonable Forth >>>>> implementation (as shown above in the register-dedication table I >>>>> provided). You do have two general-purpose registers, so you can do >>>>> code-optimization in which you hold values in general-purpose registers >>>>> temporarily rather than push them to the data-stack (VFX does code >>>>> optimization on the 32-bit x86 that has only one more register than the >>>>> PDP11 has). >>>>> >>>>> 2.) On modern processors that have 16 registers (such as the MSP430), you >>>>> can divide the registers into two banks for the main-program and the ISRs >>>>> to significantly speed up ISRs while still allowing ISRs to be written in >>>>> Forth. Your ISRs can't be interrupted though, because there is only one >>>>> bank of registers available. On the PIC24 you can also have fast ISRs >>>>> written in assembly-language that only use the lower four registers and >>>>> are able to interrupt the lower-priority ISRs that are written in Forth. >>>>> >>>>> 3.) There are HDL implementations of the PDP11 already available, so if >>>>> you want an FPGA you can use one of these as a starting point. Considering >>>>> that you (and I) have little or no experience with HDL, it seems more >>>>> realistic to start with an existing implementation rather than start from >>>>> scratch. >>>>> >>>>> 4.) There is software available for the PDP11, such as RT11, that could >>>>> still be useful. Your assembler should be compatible with whatever >>>>> assembler was used to assemble the RT11 code, except that your assembler >>>>> generates code for the MSP430, PIC24, etc.. So, if the source-code to RT11 >>>>> is available (I assume it is), you could run RT11 on an MSP430 or PIC24 or >>>>> whatever. It will be just like a George Romero movie: the dead will rise >>>>> and walk again! >>>>> >>>> >>>> I downloaded some PDP11 programming manuals and read them over several days >>>> and come to the conclusion the the PDP11 is not a good choice because is >>>> has >>>> features that a lot of modern 16 bit device do not possess mostly in the >>>> area of addressing modes, but also unique instructions. >>>> >>>> The process also impressed me why I used to love the PDP11 when I first >>>> started working with computers, my first computer I worked with was the >>>> PDP8e and the PDP11 was such a refreshing improvement, now the 64KB direct >>>> addressing limit is a pain. >>>> >>>> Right off the bat on the PDP11 all registers are equal so any register has >>>> all addressing modes, that is inefficient to implement in modern CPUs. The >>>> PDP11 also has independent addressing for each of two operands so for >>>> example an ADD instruction can have both sources to use indexed modes for >>>> the data for memory to memory operation while most modern CPUs uses a >>>> register as one of the sources/destination and the other one can be indexed >>>> but not both so in some cases it takes two instructions to do the same as >>>> one PDP11 instruction, not the end of the world but it makes things more >>>> complicated. >>>> >>>> So the choices are; >>>> >>>> 1, To map one instruction to many in some cases and use the PDP11 >>>> instruction set. >>>> 2. Use a more limited CPU like the MSP430 as a guide to the instructions >>>> instead. >>>> 3. Just invent my own mnemonics like the Go language that maps closely to >>>> existing CPUs. >>> >>> How is this distinguished from writing words in Forth? >> >> At some point the Forth is created by creating set of primitives word, one >> creates Forth primitives from assembler or High level language. Even a Meta >> compiler at some level needs words written in assembler. > > You keep walking all around the point where you clearly see what is going > on. I don't understand why you can't see it. Yes, some assembly will > always be required. That is true for *EVERY* approach you define. Inventing > an intermediate language that looks vaguely like an assembly language is no > different than just writing a few core words in Forth. Both ways you have > to write some code that generates code for your target machine. Opps, that should have been a "few core words in assembly language". -- Rick C
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web