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 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-06-01 12:08 -0700 |
| Message-ID | <b30bf143-2800-42e5-9113-ca356530ff60@googlegroups.com> |
| In reply to | #60151 |
On Thursday, June 1, 2017 at 9:27:50 AM UTC-7, Cecil - k5nwa wrote: > 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 > ... > 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. > ... > 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. The PDP11 is over-generalized, as you say. This is why most of the 1980s processors (6502, Z80, 8086) used non-orthogonal designs. The MC68000 was the cleanest design of that era --- I always thought of the 68K as a PDP11 upgrade. Just write your Forth system in PDP11 assembly-language, then afterward take note as to how you only used some of the features of the PDP11. Call this: PDP11GP --- that's 'GP' as in "good parts" --- this will be your portable-assembly-language! If you don't support the entire PDP11 instruction-set, then you can't run legacy PDP11 assembly-language programs (such as RT11) --- this may not be a concern anyway --- that is 1970s technology, so who cares? There are some cases in which two or more instructions are needed on the PDP11 for what one instruction would do on a modern processor. In this case, go ahead and add the new instruction to you PDP11GP assembler. You can still run your Forth on a PDP11 soft-core in an FPGA, but you will have to have your PDP11 version of the assembler generate the multiple instructions for the new instruction (treat it as a macro) --- alternatively, you could upgrade the HDL for the PDP11 soft-core to support your new instruction. The PDP11 is more of a loose framework to build on --- you can take away or add instructions as needed --- it is just a starting-point for the portable-assembler. > This whole project is getting more complicated and messy than > anticipated, such is life. I don't think it is that complicated and messy. Everything seems complicated and messy when it is in your head --- write down a design and begin writing code --- that usually sweeps away the messiness. I've been meaning to do this project myself, but have been distracted by other things (such is life). It is difficult to build up any enthusiasm for Forth innovation because ANS-Forth is the standard --- the purpose of ANS-Forth is to denounce all Forth innovation as being non-standard and meaningless --- the Forth-200x committee will do everything in their power to discredit a portable-assembler project because they hate the idea of portable Forth programs, and their goal is to trap the Forth community in vendor lock-in. The Forth-200x committee are the #1 enemy of Forth!
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-06-01 21:47 -0500 |
| Message-ID | <ogqjea$k08$1@dont-email.me> |
| In reply to | #60161 |
On 6/1/2017 2:08 PM, hughaguilar96@gmail.com wrote: > On Thursday, June 1, 2017 at 9:27:50 AM UTC-7, Cecil - k5nwa wrote: >> 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 >> ... >> 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. >> ... >> 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. > > The PDP11 is over-generalized, as you say. This is why most of the 1980s processors (6502, Z80, 8086) used non-orthogonal designs. The MC68000 was the cleanest design of that era --- I always thought of the 68K as a PDP11 upgrade. > > Just write your Forth system in PDP11 assembly-language, then afterward take note as to how you only used some of the features of the PDP11. Call this: PDP11GP --- that's 'GP' as in "good parts" --- this will be your portable-assembly-language! > > If you don't support the entire PDP11 instruction-set, then you can't run legacy PDP11 assembly-language programs (such as RT11) --- this may not be a concern anyway --- that is 1970s technology, so who cares? > > There are some cases in which two or more instructions are needed on the PDP11 for what one instruction would do on a modern processor. In this case, go ahead and add the new instruction to you PDP11GP assembler. You can still run your Forth on a PDP11 soft-core in an FPGA, but you will have to have your PDP11 version of the assembler generate the multiple instructions for the new instruction (treat it as a macro) --- alternatively, you could upgrade the HDL for the PDP11 soft-core to support your new instruction. > > The PDP11 is more of a loose framework to build on --- you can take away or add instructions as needed --- it is just a starting-point for the portable-assembler. > >> This whole project is getting more complicated and messy than >> anticipated, such is life. > > I don't think it is that complicated and messy. Everything seems complicated and messy when it is in your head --- write down a design and begin writing code --- that usually sweeps away the messiness. > > I've been meaning to do this project myself, but have been distracted by other things (such is life). It is difficult to build up any enthusiasm for Forth innovation because ANS-Forth is the standard --- the purpose of ANS-Forth is to denounce all Forth innovation as being non-standard and meaningless --- the Forth-200x committee will do everything in their power to discredit a portable-assembler project because they hate the idea of portable Forth programs, and their goal is to trap the Forth community in vendor lock-in. The Forth-200x committee are the #1 enemy of Forth! > This whole thing is not only to create a tool to easily migrate Forth but also a learning experience so I don't mind taking detours to learn something new. I was thinking basically the same thing last night, that I don't need to implement the whole assembler mnemonics just the stuff I need then one can add instructions that might be handy to have in other projects eventually as the need arises one can end up with a complete assembler. With that thought in mind I will start with writing a PDP11 assembler that is simple and doesn't have all the instructions using SwiftForth just for the learning experience. I'm tempted to write it using standard mnemonics instead of RPN its not that much harder. Today I been spending part of the day working on a Windows 32 bit Virtual CPU for vmWare, I have it all configured now and I will making a backup in a few minutes, tomorrow I will work on the same thing for VirtualBox, why two because each has their own strong points. Most of my licensed VMs are for use with vmWare, it's slightly faster but not as friendly as VirtualBox. There are several free PDP11 emulators, some of them come with options for downloading up to six different OSes including System V Unix, RT11 is plain but it works fine. The more I read about the PDP11 the mode I like the sucker, it's been 40 years since I last worked on it so I forgotten a lot of the details but so far it's even better that what I remember it was a PDP11-45 a micro-coded beast. A FPGA implementation is way faster than the real thing. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-06-02 06:34 -0700 |
| Message-ID | <084e603f-3504-414a-a068-6bcd64d7c1a4@googlegroups.com> |
| In reply to | #60176 |
On Thursday, June 1, 2017 at 7:47:58 PM UTC-7, Cecil - k5nwa wrote: > I'm tempted to write it using standard > mnemonics instead of RPN its not that much harder. You are better of with a traditional RPN Forth assembler. This works well for meta-compiling because you can have a macro that generates machine-code and you give it parameters on the data-stack that will be the operands. In a cross-compiler, this is very common --- when I did this before in MFX, I had a lot of meta-compiling --- I didn't really write raw assembly-language myself very much.
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2017-06-02 07:13 -0700 |
| Message-ID | <aa93fd58-e967-4480-bc91-3a42c9ccddc5@googlegroups.com> |
| In reply to | #60193 |
On Friday, June 2, 2017 at 9:34:26 AM UTC-4, hughag...@gmail.com wrote: > On Thursday, June 1, 2017 at 7:47:58 PM UTC-7, Cecil - k5nwa wrote: > > I'm tempted to write it using standard > > mnemonics instead of RPN its not that much harder. > > You are better of with a traditional RPN Forth assembler. This works well for meta-compiling because you can have a macro that generates machine-code and you give it parameters on the data-stack that will be the operands. In a cross-compiler, this is very common --- when I did this before in MFX, I had a lot of meta-compiling --- I didn't really write raw assembly-language myself very much. I agree with you Hugh. Bringing up a simple RPN assembler for a new machine is usually pretty quick and then you can make it into what ever you need. I used that feature of RPN assemblers with my hobby 9900 assembler to allow me to get things on and off the stacks with code macros called POP, PUSH, RPOP, and RPUSH,. Very quickly the assembler code looks like the machine supports 2 stacks. And that's the simplest level of abstraction. In this entire conversation I have not heard anyone mention that common wisdom is that it is faster to get Forth running on new machine than waking up a C compiler (or any of language compiler) for a new machine. So TRUE or FALSE? The process of using Forth to create a new Assembler, coding the primitives and then using the primitives to cross compile a new Forth is REALLY the fastest way to wake up new iron or is that an urban legend propagated in Forth circles ?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-06-02 07:57 -0700 |
| Message-ID | <2a9a014d-fe75-4937-b29e-77c6a41c92c3@googlegroups.com> |
| In reply to | #60196 |
On Friday, June 2, 2017 at 7:13:11 AM UTC-7, foxaudio...@gmail.com wrote: > On Friday, June 2, 2017 at 9:34:26 AM UTC-4, hughag...@gmail.com wrote: > > On Thursday, June 1, 2017 at 7:47:58 PM UTC-7, Cecil - k5nwa wrote: > > > I'm tempted to write it using standard > > > mnemonics instead of RPN its not that much harder. > > > > You are better of with a traditional RPN Forth assembler. This works well for meta-compiling because you can have a macro that generates machine-code and you give it parameters on the data-stack that will be the operands. In a cross-compiler, this is very common --- when I did this before in MFX, I had a lot of meta-compiling --- I didn't really write raw assembly-language myself very much. > > I agree with you Hugh. Bringing up a simple RPN assembler for a new machine is > usually pretty quick and then you can make it into what ever you need. If you have users who demand a traditional assembler such as MACRO-11, then this can be written as a wrapper on top of the RPN assembler that was easy to write --- that would be if you have users who are paying you money --- I wouldn't otherwise bother with requests from non-Forthers who want me to make Forth look like a traditional language, before they can spring into action and start programming. > So TRUE or FALSE? > The process of using Forth to create a new Assembler, coding the primitives > and then using the primitives to cross compile a new Forth is REALLY the > fastest way to wake up new iron or is that an urban legend propagated in Forth > circles ? That is what I did for the MiniForth processor when I was hired at Testra to write the assembler and Forth compiler for it. If Anton Ertl had been hired by Testra for this job, they would have found him in his office sleeping on the couch. After waking him up, and asking him what progress was being made on the MiniForth development system, he would have replied: "I'm waiting for the heroic GCC developers to produce a version of GCC that targets the MiniForth processor. As soon as they do, then I will spring into action and port gForth over to it! This might take some time, because the GCC developers aren't getting paid to support the MiniForth and have no motivation to do this work, so we might as well catch up on our sleep while we wait. My plan for speeding up the GCC developers is to mail them a box of Girl Scout cookies --- that should provide them with the needed fuel for all of this work that we need them to do! Also, I'm going to stop complaining on comp.lang.c about how GCC is not compliant with ANSI-C because I know that the GCC developers find my endless whining to be irksome, and they consider me to be a troll. BTW: Is it Friday yet? Did you bring my paycheck?" This is why Anton Ertl is not employed at Testra, but instead works as the Forth-200x committee chair-person. Of course, I haven't been employed at Testra in almost 20 years either --- there is no money in Forth programming --- it is a dead-end job with no hope for advancement. After ANS-Forth became the standard, Forth died --- nowadays there are thousands of new help-wanted ads for ARM/GCC programmers every year --- the number of help-wanted ads for Forth programmers is exactly zilch.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-06-03 02:17 +0200 |
| Message-ID | <ogsv6u$uv6$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #60193 |
In article <084e603f-3504-414a-a068-6bcd64d7c1a4@googlegroups.com>, <hughaguilar96@gmail.com> wrote: >On Thursday, June 1, 2017 at 7:47:58 PM UTC-7, Cecil - k5nwa wrote: >> I'm tempted to write it using standard=20 >> mnemonics instead of RPN its not that much harder. > >You are better of with a traditional RPN Forth assembler. This works well f= >or meta-compiling because you can have a macro that generates machine-code = >and you give it parameters on the data-stack that will be the operands. In = >a cross-compiler, this is very common --- when I did this before in MFX, I = >had a lot of meta-compiling --- I didn't really write raw assembly-language= > myself very much. There is no particular advantage to using rpn for an assembler. An instruction consists of pieces that can be put together in any order. Having the mnemonic for the action first is in fact advantageous because it sets the stage for what follows. Read more in postitfixup.html on my site below or look at the built in Pentium assembler of lina/wina. Screen 191 and following. Groetjes Albert -- 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 21:07 -0500 |
| Message-ID | <ogfvje$bma$1@dont-email.me> |
| In reply to | #59988 |
On 5/28/2017 4:45 PM, hughaguilar96@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: >> >> 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). > > 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). > >> 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. > I wish it did then it would be a decent Forth but as it is they tried to please everyone and ended with a lot of ambiguity. > 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 -- > The data shuffling is a royal pain and a killer of efficiency, you end up running a lot of code that does not solve your application because data needs to be accessed. That is one reason wy people like Algol like languages because this is handled for you. > 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. > If you have registers capable of implementing a stack the why stop at two? >> 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. > OK but I like the DO LOOP because its easy to use and the I local is very handy at times and helps you avoid doing unnecessary math. > 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. > I'm not familiar with these techniques as I mostly have used older Forth where these are not available. Maybe I have used something similar in Delphi but they would be called something else, I do recall writing code where a function defined inside another function can access the data of the parent and change that data, but I forget what it was called. I used it to eliminate the passing of a whole lot of data to a function. >> Thanks for reminding me about PAC (Portab le 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. All those processors are nice to work with, add to that the dsPIC as it is an enhanced PIC24, very nice and is also available in DIP packaging so its easy to experiment with. Somewhere I have a PDF file which is a copy of the PDP11 programmers manual, I'll look at it, but the MSP430 is also a good choice. Somewhere filed away is a MSP430 IP for FPGA, the one advantage it has is it uses a 200MHz clock so it really flies. > > 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. > There are a couple of old CPUs that eventually I want to build either a board or a FPGA version, the Z80, MC6809, 6502 or its modern version the W65C816. > 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. There are so many ways to optimize code, many books have been written on the subject and it is an interesting subject. The times I have written optimizing code generators which is for about 12 different CPUs I been off the beaten path and done it my way which generally not how it is found in compiler books. It may not be the most optimum way of doing it but I don't care to be a lemming, it works good enough and it's simple enough. I feel the same way about Forth I like what I like and too bad if the rest of the world does not agree. But I'm always willing to learn something new or a better way to do things. One day you need to try it it's a lot of fun watching simply generated code turn into an object of beauty and efficiency. > > 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." > Really, I could not tell. I've heard rumors that you are not a happy camper when it comes to ANS Forth is there anything to that rumor? -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-28 21:48 -0700 |
| Message-ID | <dd2e97ba-d74f-4fa6-ba2a-508600be58c8@googlegroups.com> |
| In reply to | #59996 |
On Sunday, May 28, 2017 at 7:07:59 PM UTC-7, Cecil - k5nwa wrote: > > 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. > > If you have registers capable of implementing a stack the why stop at two? What primitive data-type does not fit in either one or two cells? I would think that a single-cell data-stack and a double-cell data-stack would pretty much cover every primitive data-type. If you have data-types that are bigger than two cells, then you are going to have to just make a struct in the heap and hold a pointer on the data-stack. The ALLOCATE and FREE will make this slower, but it is workable, even on a micro-controller. > > 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. > > OK but I like the DO LOOP because its easy to use and the I local is > very handy at times and helps you avoid doing unnecessary math. I would recommend enhanced versions of BEGIN WHILE REPEAT --- you still use locals --- but the arithmetic is hidden from the user. Basically, these are macros that generate BEGIN WHILE REPEAT and the code to do the advancement of the index along with the comparison of the index to the limit --- don't worry --- it is easy. > > 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. > > I'm not familiar with these techniques as I mostly have used older Forth > where these are not available. Maybe I have used something similar in > Delphi but they would be called something else, I do recall writing code > where a function defined inside another function can access the data of > the parent and change that data, but I forget what it was called. I used > it to eliminate the passing of a whole lot of data to a function. You're not familiar with these techniques because there is no Forth, old or new, that does this --- it is just something that I made up. I don't know Delphi, but I did read a book on Pascal-S way back in high-school, that provided source-code for a compiler. This Pascal had nested functions. It also had a "display table" that allowed the parent function's locals to be visible in the nested function when it executed. Pretty complicated! My quotations are much simpler, although not as versatile. > There are a couple of old CPUs that eventually I want to build either a > board or a FPGA version, the Z80, MC6809, 6502 or its modern version the > W65C816. What is your goal? Do you have some application in mind? Or do you just enjoy programming and want to play with one of these old processors because they are cool? You might try one of those Rabbit boards if you are interested in the Z80 --- they look like fun --- I haven't tried them though. The 6809 and 65c816 both score high on the coolometer --- they aren't practical though --- the ARM is the practical choice for pretty much everything. > > 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. > > There are so many ways to optimize code, many books have been written on > the subject and it is an interesting subject. The times I have written > optimizing code generators which is for about 12 different CPUs I been > off the beaten path and done it my way which generally not how it is > found in compiler books. It may not be the most optimum way of doing it > but I don't care to be a lemming, it works good enough and it's simple > enough. I feel the same way about Forth I like what I like and too bad > if the rest of the world does not agree. But I'm always willing to learn > something new or a better way to do things. > > One day you need to try it it's a lot of fun watching simply generated > code turn into an object of beauty and efficiency. Recently I have been giving some thought to writing a Pascal compiler for either the 80c320 or the PIC18 --- that may be my next project --- write it in VFX using the novice-package, and use a code optimization technique that I thought of way back in 1994 but never implemented. I actually do know a little bit about Pascal compilers (that book I mentioned, for one thing), although I've only written a few small programs in Pascal (I liked QuickPascal back in MS-DOS days, and Turbo Pascal on the CP/M machines before that). BTW: Lemmings don't actually follow each other over a cliff in a mass-suicide as most people believe: http://www.adfg.alaska.gov/index.cfm?adfg=wildlifenews.view_article&articles_id=56
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-29 00:52 -0500 |
| Message-ID | <oggcp9$cvb$1@dont-email.me> |
| In reply to | #60002 |
On 5/28/2017 11:48 PM, hughaguilar96@gmail.com wrote: > On Sunday, May 28, 2017 at 7:07:59 PM UTC-7, Cecil - k5nwa wrote: >>> 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. >> >> If you have registers capable of implementing a stack the why stop at two? > > What primitive data-type does not fit in either one or two cells? I would think that a single-cell data-stack and a double-cell data-stack would pretty much cover every primitive data-type. > > If you have data-types that are bigger than two cells, then you are going to have to just make a struct in the heap and hold a pointer on the data-stack. The ALLOCATE and FREE will make this slower, but it is workable, even on a micro-controller. > >>> 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. >> >> OK but I like the DO LOOP because its easy to use and the I local is >> very handy at times and helps you avoid doing unnecessary math. > > I would recommend enhanced versions of BEGIN WHILE REPEAT --- you still use locals --- but the arithmetic is hidden from the user. > > Basically, these are macros that generate BEGIN WHILE REPEAT and the code to do the advancement of the index along with the comparison of the index to the limit --- don't worry --- it is easy. > >>> 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. >> >> I'm not familiar with these techniques as I mostly have used older Forth >> where these are not available. Maybe I have used something similar in >> Delphi but they would be called something else, I do recall writing code >> where a function defined inside another function can access the data of >> the parent and change that data, but I forget what it was called. I used >> it to eliminate the passing of a whole lot of data to a function. > > You're not familiar with these techniques because there is no Forth, old or new, that does this --- it is just something that I made up. > > I don't know Delphi, but I did read a book on Pascal-S way back in high-school, that provided source-code for a compiler. This Pascal had nested functions. It also had a "display table" that allowed the parent function's locals to be visible in the nested function when it executed. Pretty complicated! My quotations are much simpler, although not as versatile. Delphi is Pascal on steroids, an excellent development environment with an excellent debugger and tools to deal with Windows, Linux, or MacOS. I looked it up and Delphi has both HOFs and quotations. Those were very useful and I used them a lot in a BT+ Database library routines, very handy passing routines and accessing the parents variables. HOFs I believe are possible in Forth with no changes, but would not quotations require changes to Forth? Is there even a standard way of storing locals? >> There are a couple of old CPUs that eventually I want to build either a >> board or a FPGA version, the Z80, MC6809, 6502 or its modern version the >> W65C816. > > What is your goal? Do you have some application in mind? Or do you just enjoy programming and want to play with one of these old processors because they are cool? > > You might try one of those Rabbit boards if you are interested in the Z80 --- they look like fun --- I haven't tried them though. > > The 6809 and 65c816 both score high on the coolometer --- they aren't practical though --- the ARM is the practical choice for pretty much everything. > There are some FPGA MC6809 implementations that are free and extremely fast. For the 65c816 the chip cost around $7 at Mouser, add some RAM and some EPROMs with a small amount of logic and you are in business. That chip is very nice comes up in 6502 compatibility mode then you can turn the extra features. I'm just having fun, I'm retired due to health issues and I have a very long list of things I would like to try out. I don't have a ton of money but these kinds of projects are low cost so I can indulge away. For a real project I would use something more current with an ARM, MSP430, or dsPIC device they are all pretty inexpensive specially the ARM boards. The Rabbit is fairly fast for the money some decent ones are $40 to $50 and all I need is one, the rest is pretty much free, make some changes to a Forth compiler and voila a native compiler no expenses involved just a little bit of time. >>> 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. >> >> There are so many ways to optimize code, many books have been written on >> the subject and it is an interesting subject. The times I have written >> optimizing code generators which is for about 12 different CPUs I been >> off the beaten path and done it my way which generally not how it is >> found in compiler books. It may not be the most optimum way of doing it >> but I don't care to be a lemming, it works good enough and it's simple >> enough. I feel the same way about Forth I like what I like and too bad >> if the rest of the world does not agree. But I'm always willing to learn >> something new or a better way to do things. >> >> One day you need to try it it's a lot of fun watching simply generated >> code turn into an object of beauty and efficiency. > > Recently I have been giving some thought to writing a Pascal compiler for either the 80c320 or the PIC18 --- that may be my next project --- write it in VFX using the novice-package, and use a code optimization technique that I thought of way back in 1994 but never implemented. > > I actually do know a little bit about Pascal compilers (that book I mentioned, for one thing), although I've only written a few small programs in Pascal (I liked QuickPascal back in MS-DOS days, and Turbo Pascal on the CP/M machines before that). Borland made Turbo Pascal and other Turbo products like Turbo C and Turbo Prolog I own them all, later it evolved into the Delphi and C++ Builder development environment. I have several copies of Delphi and C++ Builder the latest being version 7 but it won't run in Windows 10 64 bits, I need when I have some time install it on my 32 bit Windows 7 machine, I believe it will run there just fine. The people that bought Borland (Embarcadero) think too much of themselves and a copy of Delphi now cost around $1700. > > BTW: Lemmings don't actually follow each other over a cliff in a mass-suicide as most people believe: > http://www.adfg.alaska.gov/index.cfm?adfg=wildlifenews.view_article&articles_id=56 > I know that but is now means to most people, following the crowd without thinking to disastrous results, sounds familiar? -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-29 09:17 -0700 |
| Message-ID | <224d03a6-8c72-4eea-9021-72052056c44d@googlegroups.com> |
| In reply to | #60006 |
On Sunday, May 28, 2017 at 10:52:58 PM UTC-7, Cecil - k5nwa wrote: > On 5/28/2017 11:48 PM, hughaguilar96@gmail.com wrote: > > I don't know Delphi, but I did read a book on Pascal-S way back in high-school, that provided source-code for a compiler. This Pascal had nested functions. It also had a "display table" that allowed the parent function's locals to be visible in the nested function when it executed. Pretty complicated! My quotations are much simpler, although not as versatile. > > Delphi is Pascal on steroids, an excellent development environment with > an excellent debugger and tools to deal with Windows, Linux, or MacOS. I > looked it up and Delphi has both HOFs and quotations. Those were very > useful and I used them a lot in a BT+ Database library routines, very > handy passing routines and accessing the parents variables. I actually bought a copy of Kylix, which is the Linux version of Borland Delphi, when CompUSA was going out of business and they had all those shrink-wrapped boxes of disks and manuals in the bargain-bin for $5. In never used it though. AFAIK, Borland Delphi and Kylix were quite powerful --- everybody spoke well of them. Java became the standard and killed off Pascal and (to a lessor extent) C++. Weirdly enough, everybody speaks ill of Java --- it doesn't have anything like quotations or HOFs. I think languages mostly become popular because they are perceived as being "the next big thing" --- a classic example of being famous for being famous. Have you tried any of the free versions of Pascal, such as Lazerus? If I do write a Pascal compiler, I should have a Pascal available on the desktop-computer to help me relearn it. > HOFs I > believe are possible in Forth with no changes, but would not quotations > require changes to Forth? > > Is there even a standard way of storing locals? How could you have HOFs without quotations??? I have my rquotations working under VFX and SwiftForth. It should be possible to implement them under any Forth compiler, but carnal knowledge is required. It is just a matter of declaring them to be standard --- then the carnal knowledge is hidden from the user --- same as everything else (for example, division requires carnal knowledge, but that doesn't prevent us from having division in the standard). The Forth-200x committee will never accept rquotations --- the committe is 100% committed to the Paysan-faked quotations that are utterly useless --- Stephen Pelc wrote an article in which he said that quotations aren't possible in Forth and so they have to be faked (this article was the basis for the Paysan-faked quotations, and the RfD is pretty much just the article copied word-for-word). > For the 65c816 the chip cost around $7 at Mouser, add some RAM and > some EPROMs with a small amount of logic and you are in business. That > chip is very nice comes up in 6502 compatibility mode then you can turn > the extra features. If you build a 65c816 experimenter board, you can likely sell it to everybody (including myself) on the 6502 forum. This is not a big market, but it is infinitely larger than zero! The 65c816 is not the best choice for serious work, because the ARM dominates. It is not a bad choice though --- somebody could build a product based on the 65c816 though, and it would be reasonably competitive --- so the 65c816 shouldn't be totally dismissed as obsolete. The STM8 is pretty popular for low-performance applications that need a lot of memory, which is also what the 65c816 is used for --- in many cases, waiting a few microseconds for a result is okay --- not every project needs the most powerful processor available, that can bend space-time and provide you with a result before you ask for it. > The Rabbit is fairly fast for the money some decent ones are $40 to $50 > and all I need is one, the rest is pretty much free, make some changes > to a Forth compiler and voila a native compiler no expenses involved > just a little bit of time. Most of the cost of the Rabbit is there because you get to use Dynamic C that only works on the Rabbit. If you are not going to use Dynamic C, but are going to write your own Forth, then you would be better off to buy an eZ80 from Zilog that is more powerful and costs less. I have an experimenter board for the eZ80 --- I attended a seminar at Zilog in San Jose and bought it there --- I have never really done anything with the eZ80 though, and it is in the same category as the 65c816 now (pretty much obsolete). > The people that bought > Borland (Embarcadero) think too much of themselves and a copy of Delphi > now cost around $1700. VFX is also pretty pricey --- I'm not going to buy it either --- this is why Juergen Pintaske says that I "don't understand how the corporate world works" and that I'm a "Forth killer" because I write Forth code and distribute it in the novice-package.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-29 12:16 -0500 |
| Message-ID | <oghkrt$kkk$1@dont-email.me> |
| In reply to | #60018 |
On 5/29/2017 11:17 AM, hughaguilar96@gmail.com wrote: > On Sunday, May 28, 2017 at 10:52:58 PM UTC-7, Cecil - k5nwa wrote: >> Delphi is Pascal on steroids, an excellent development environment with >> an excellent debugger and tools to deal with Windows, Linux, or MacOS. I >> looked it up and Delphi has both HOFs and quotations. Those were very >> useful and I used them a lot in a BT+ Database library routines, very >> handy passing routines and accessing the parents variables. > > I actually bought a copy of Kylix, which is the Linux version of Borland Delphi, when CompUSA was going out of business and they had all those shrink-wrapped boxes of disks and manuals in the bargain-bin for $5. In never used it though. AFAIK, Borland Delphi and Kylix were quite powerful --- everybody spoke well of them. Java became the standard and killed off Pascal and (to a lessor extent) C++. Weirdly enough, everybody speaks ill of Java --- it doesn't have anything like quotations or HOFs. I think languages mostly become popular because they are perceived as being "the next big thing" --- a classic example of being famous for being famous. > > Have you tried any of the free versions of Pascal, such as Lazerus? If I do write a Pascal compiler, I should have a Pascal available on the desktop-computer to help me relearn it. > Only for a few small test programs and it worked fine, it emulates an older version of Delphi but it does install and work in Windows 10 and Linux. I been told by some that use it on a regular basis that it works quite well and is very reliable so it might be something in my future, Pascal unlike C or C++ can have optional run time checks that makes life easier at catching some type of normally hard to find problems. I'm building a Linux system on one of my nicest CPUs an i7, 3.4GHz, 24GB RAM and I installed FreePascal and Lazarus on it, it is part of evaluating the use of Linux as a everyday/programming platform instead of Windows, it's a low priority project, a couple of days ago I installed Go, and the Visual Studio Code software, so far everything is doing well and the PC is quite fast. I also figured out how to move VirtualBox and vmWare licensed VMs from Windows to Linux and not loose the license, I had to do it a little different than what people suggested but its working rather well. >> HOFs I >> believe are possible in Forth with no changes, but would not quotations >> require changes to Forth? >> >> Is there even a standard way of storing locals? > > How could you have HOFs without quotations??? > > I have my rquotations working under VFX and SwiftForth. It should be possible to implement them under any Forth compiler, but carnal knowledge is required. It is just a matter of declaring them to be standard --- then the carnal knowledge is hidden from the user --- same as everything else (for example, division requires carnal knowledge, but that doesn't prevent us from having division in the standard). > Maybe I don't understand Forth HOFs then, the term has existed for a while and Delphi and C have the capability. In the classical sense a HOF is a function that can have pointers to functions passed to it, it also has the ability to return pointers to functions. In that sense Forth has HOFs already, and there is nothing new needed. They are handy is some types of programs. Classical quotations are functions that defined inside a function so when executed they have access to their parents data, both reading and writing. Again a very useful tool. In Delphi the two are separate items and need not be used together but they often are. > The Forth-200x committee will never accept rquotations --- the committe is 100% committed to the Paysan-faked quotations that are utterly useless --- Stephen Pelc wrote an article in which he said that quotations aren't possible in Forth and so they have to be faked (this article was the basis for the Paysan-faked quotations, and the RfD is pretty much just the article copied word-for-word). > I look at the discussions on the subject and wonder why they want to put in quotations that don't work, whats the point, in Delphi and other languages the whole purpose behind quotations it to access or change the parents data. I think it's another case of 1970 thinking. >> For the 65c816 the chip cost around $7 at Mouser, add some RAM and >> some EPROMs with a small amount of logic and you are in business. That >> chip is very nice comes up in 6502 compatibility mode then you can turn >> the extra features. > > If you build a 65c816 experimenter board, you can likely sell it to everybody (including myself) on the 6502 forum. This is not a big market, but it is infinitely larger than zero! > > The 65c816 is not the best choice for serious work, because the ARM dominates. It is not a bad choice though --- somebody could build a product based on the 65c816 though, and it would be reasonably competitive --- so the 65c816 shouldn't be totally dismissed as obsolete. > > The STM8 is pretty popular for low-performance applications that need a lot of memory, which is also what the 65c816 is used for --- in many cases, waiting a few microseconds for a result is okay --- not every project needs the most powerful processor available, that can bend space-time and provide you with a result before you ask for it. > Its just for fun and a learning experience, the STM8 devices are interesting you can buy some boards for less than $2 that are quite useful for small projects. >> The Rabbit is fairly fast for the money some decent ones are $40 to $50 >> and all I need is one, the rest is pretty much free, make some changes >> to a Forth compiler and voila a native compiler no expenses involved >> just a little bit of time. > > Most of the cost of the Rabbit is there because you get to use Dynamic C that only works on the Rabbit. > > If you are not going to use Dynamic C, but are going to write your own Forth, then you would be better off to buy an eZ80 from Zilog that is more powerful and costs less. I have an experimenter board for the eZ80 --- I attended a seminar at Zilog in San Jose and bought it there --- I have never really done anything with the eZ80 though, and it is in the same category as the 65c816 now (pretty much obsolete). I have some ez80 boards on my Mouser Project list, one of these days I'll get one. > >> The people that bought >> Borland (Embarcadero) think too much of themselves and a copy of Delphi >> now cost around $1700. > > VFX is also pretty pricey --- I'm not going to buy it either --- this is why Juergen Pintaske says that I "don't understand how the corporate world works" and that I'm a "Forth killer" because I write Forth code and distribute it in the novice-package. > If you are going to eventually write your own Pascal I would look at the Borland/Lazarus software as models they are very similar, Lazarus source is available for one to look at for ideas. Lazarus is written in Lazarus, if you are going to use MPEs VFX to write it that should be an interesting project, pretty involved. One thing about doing it that way is the powerful tools built into Forth that can make your life easier like using their built in code generator and optimizer but that only works for a Intel CPU version. The easiest way to build a Pascal compiler is using a recursive decent parser which naturally generates as it's output RPN code how about that for nicely generating object code with a Forth Compiler. I will be spending some time today becoming familiar again with my Macro Processors and used them to translate PAC code to a real CPU code and see how well it works, but all of that will take some time, over the next few days my task will be to familiarize myself with software that will be an interesting test of my memory which I think is not as good as it used to be. Unfortunately I have the source code to the software but not some of the sample projects, that would help me remember me but they are history. I do have some very old computers in the garage but the really old ones that would have the software were given away so hopefully there is an old macro processor project in there somewhere. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-29 19:21 -0700 |
| Message-ID | <0fee3892-c86e-4d78-b925-7c97bc4f2a4c@googlegroups.com> |
| In reply to | #60019 |
On Monday, May 29, 2017 at 10:17:03 AM UTC-7, Cecil - k5nwa wrote: > On 5/29/2017 11:17 AM, hughaguilar96@gmail.com wrote: > >> HOFs I > >> believe are possible in Forth with no changes, but would not quotations > >> require changes to Forth? > >> > >> Is there even a standard way of storing locals? > > > > How could you have HOFs without quotations??? > > > > I have my rquotations working under VFX and SwiftForth. It should be possible to implement them under any Forth compiler, but carnal knowledge is required. It is just a matter of declaring them to be standard --- then the carnal knowledge is hidden from the user --- same as everything else (for example, division requires carnal knowledge, but that doesn't prevent us from having division in the standard). > > Maybe I don't understand Forth HOFs then, the term has existed for a > while and Delphi and C have the capability. In the classical sense a HOF > is a function that can have pointers to functions passed to it, it also > has the ability to return pointers to functions. In that sense Forth has > HOFs already, and there is nothing new needed. They are handy is some > types of programs. Classical quotations are functions that defined > inside a function so when executed they have access to their parents > data, both reading and writing. Again a very useful tool. In Delphi the > two are separate items and need not be used together but they often are. Yes, Forth has always had the ability to pass an XT into function, and that function is a HOF. I do this a lot in the novice-package, but the XT is just a pseudo-quotation because it is just an ordinary colon word or :NONAME word. The Paysan-faked quotations are also pseudo-quotations because they are just :NONAME words with some syntactic sugar. So, I was incorrect to say that you can't have HOFs without quotations --- you can have HOFs with pseudo-quotations too --- they are a lot more useful with real quotations though (quotations that can access the parent function's local variables). Note that my rquotations are neither real quotations nor pseudo-quotations --- lets call them realish quotations! They are significantly more useful than pseudo-quotations because they do have access to the parent function's local variables. They do have some limitations though: 1.) They aren't XT values, so they aren't known at compile-time (mostly this means that they can't be used with <SWITCH structures). 2.) The HOF called by the parent function has to have local variables, and it has to execute the rquotation (it can't call another function that has local variables and that function executes the rquotation). For the most part, these limitations are not a problem. Not being known at compile-time (#1 above) is a minor problem because <SWITCH has to use :NONAME words that can't share local variables, but have to use global variables to communicate with each other. This is somewhat clunky, but not a big problem. I'm writing a simulator for the 65c02 right now, and it won't be reentrant. This would be a problem if you wanted to simulate more than one 65c02 at the same time, but this is somewhat unlikely. Also, there are ways to work around this problem anyway --- it is just somewhat clunky. As for #2 above, I can't think of any case in which this would be a problem. All in all, rquotations do everything that I really need --- just for the sake of purity, I would rather have real quotations rather than realish quotations --- but the realish ones are, from a practical standpoint, adequate. By comparison, the Paysan-faked quotations are worse than useless --- I say "worse than useless" because they pretend to be quotations when they are just pseudo-quotations --- they give the Forth community the reputation of being liars who fake language features that they are too dumb to implement. > > The Forth-200x committee will never accept rquotations --- the committe is 100% committed to the Paysan-faked quotations that are utterly useless --- Stephen Pelc wrote an article in which he said that quotations aren't possible in Forth and so they have to be faked (this article was the basis for the Paysan-faked quotations, and the RfD is pretty much just the article copied word-for-word). > > I look at the discussions on the subject and wonder why they want to put > in quotations that don't work, whats the point, in Delphi and other > languages the whole purpose behind quotations it to access or change the > parents data. I think it's another case of 1970 thinking. They committed themselves to the Paysan-faked quotations because they didn't know how to do rquotations --- if they had thought of rquotations, they would have done that instead --- but now that I have thought of rquotations, they aren't going to accept rquotations, but will instead remain steadfast on the Paysan-faked quotations. This is human-nature --- the Forth-200x committee can't admit that they were wrong --- they can't admit that somebody else (myself and HumptyDumpty) can figure things out that they are too dumb to figure out (because they are the "leading experts" of Forth and are hence superior to all other Forth programmers, or so they claim). The Forth-200x committee complain that this is a thankless job --- that is because they are screwing it up, and then white-washing their screw-ups --- if they did a better job, they might get thanked!
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-29 23:13 -0500 |
| Message-ID | <ogirap$c9r$1@dont-email.me> |
| In reply to | #60035 |
On 5/29/2017 9:21 PM, hughaguilar96@gmail.com wrote: > On Monday, May 29, 2017 at 10:17:03 AM UTC-7, Cecil - k5nwa wrote: >> On 5/29/2017 11:17 AM, hughaguilar96@gmail.com wrote: >>>> HOFs I >>>> believe are possible in Forth with no changes, but would not quotations >>>> require changes to Forth? >>>> >>>> Is there even a standard way of storing locals? >>> >>> How could you have HOFs without quotations??? >>> >>> I have my rquotations working under VFX and SwiftForth. It should be possible to implement them under any Forth compiler, but carnal knowledge is required. It is just a matter of declaring them to be standard --- then the carnal knowledge is hidden from the user --- same as everything else (for example, division requires carnal knowledge, but that doesn't prevent us from having division in the standard). >> >> Maybe I don't understand Forth HOFs then, the term has existed for a >> while and Delphi and C have the capability. In the classical sense a HOF >> is a function that can have pointers to functions passed to it, it also >> has the ability to return pointers to functions. In that sense Forth has >> HOFs already, and there is nothing new needed. They are handy is some >> types of programs. Classical quotations are functions that defined >> inside a function so when executed they have access to their parents >> data, both reading and writing. Again a very useful tool. In Delphi the >> two are separate items and need not be used together but they often are. > > Yes, Forth has always had the ability to pass an XT into function, and that function is a HOF. I do this a lot in the novice-package, but the XT is just a pseudo-quotation because it is just an ordinary colon word or :NONAME word. The Paysan-faked quotations are also pseudo-quotations because they are just :NONAME words with some syntactic sugar. > > So, I was incorrect to say that you can't have HOFs without quotations --- you can have HOFs with pseudo-quotations too --- they are a lot more useful with real quotations though (quotations that can access the parent function's local variables). > > Note that my rquotations are neither real quotations nor pseudo-quotations --- lets call them realish quotations! They are significantly more useful than pseudo-quotations because they do have access to the parent function's local variables. They do have some limitations though: > > 1.) They aren't XT values, so they aren't known at compile-time (mostly this means that they can't be used with <SWITCH structures). > > 2.) The HOF called by the parent function has to have local variables, and it has to execute the rquotation (it can't call another function that has local variables and that function executes the rquotation). > > For the most part, these limitations are not a problem. Not being known at compile-time (#1 above) is a minor problem because <SWITCH has to use :NONAME words that can't share local variables, but have to use global variables to communicate with each other. This is somewhat clunky, but not a big problem. I'm writing a simulator for the 65c02 right now, and it won't be reentrant. This would be a problem if you wanted to simulate more than one 65c02 at the same time, but this is somewhat unlikely. Also, there are ways to work around this problem anyway --- it is just somewhat clunky. As for #2 above, I can't think of any case in which this would be a problem. > > All in all, rquotations do everything that I really need --- just for the sake of purity, I would rather have real quotations rather than realish quotations --- but the realish ones are, from a practical standpoint, adequate. By comparison, the Paysan-faked quotations are worse than useless --- I say "worse than useless" because they pretend to be quotations when they are just pseudo-quotations --- they give the Forth community the reputation of being liars who fake language features that they are too dumb to implement. > >>> The Forth-200x committee will never accept rquotations --- the committe is 100% committed to the Paysan-faked quotations that are utterly useless --- Stephen Pelc wrote an article in which he said that quotations aren't possible in Forth and so they have to be faked (this article was the basis for the Paysan-faked quotations, and the RfD is pretty much just the article copied word-for-word). >> >> I look at the discussions on the subject and wonder why they want to put >> in quotations that don't work, whats the point, in Delphi and other >> languages the whole purpose behind quotations it to access or change the >> parents data. I think it's another case of 1970 thinking. > > They committed themselves to the Paysan-faked quotations because they didn't know how to do rquotations --- if they had thought of rquotations, they would have done that instead --- but now that I have thought of rquotations, they aren't going to accept rquotations, but will instead remain steadfast on the Paysan-faked quotations. > > This is human-nature --- the Forth-200x committee can't admit that they were wrong --- they can't admit that somebody else (myself and HumptyDumpty) can figure things out that they are too dumb to figure out (because they are the "leading experts" of Forth and are hence superior to all other Forth programmers, or so they claim). > > The Forth-200x committee complain that this is a thankless job --- that is because they are screwing it up, and then white-washing their screw-ups --- if they did a better job, they might get thanked! > I have not read on it but how are ANS locals implemented? Once I implemented locals in a very poor way I think, I created a word that allocated a buffer area, then the local creating word would allocate space from that area but at runtime it would calculate the address of the variable and fetch it or store data for you. Did think much about it but I was doing an application and the stack data was getting out of hand hard to keep track and get to the data so I had named variables that were easy to use, it worked. If I used the user area as the buffer they were global variables, if I used a private buffer then they were local to the word that created them. It was a little more complex than that but they did the trick. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-05-30 01:07 -0700 |
| Message-ID | <87ziduoji3.fsf@nightsong.com> |
| In reply to | #60043 |
Cecil Bayona <cbayona@cbayona.com> writes: > I have not read on it but how are ANS locals implemented? I don't think they prescribe an implementation technique, but the usual approaches are put them in the return stack (maybe with a frame pointer), or put them in a separate locals stack. Either way you need a temporary wordlist, and stuff to clean it all up on returning from the function or if something throws an exception.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-30 15:54 +0100 |
| Message-ID | <ogk0sl$9n2$1@dont-email.me> |
| In reply to | #60035 |
On 5/30/2017 03:21, hughaguilar96@gmail.com wrote: > On Monday, May 29, 2017 at 10:17:03 AM UTC-7, Cecil - k5nwa wrote: >> On 5/29/2017 11:17 AM, hughaguilar96@gmail.com wrote: > > Yes, Forth has always had the ability to pass an XT into function, > and that function is a HOF. I do this a lot in the novice-package, > but the XT is just a pseudo-quotation because it is just an ordinary > colon word or :NONAME word. The Paysan-faked quotations are also > pseudo-quotations because they are just :NONAME words with some > syntactic sugar. > > So, I was incorrect to say that you can't have HOFs without > quotations That's a welcome start. > > Note that my rquotations are neither real quotations nor > pseudo-quotations --- lets call them realish quotations! They are > significantly more useful than pseudo-quotations because they do have > access to the parent function's local variables. They do have some > limitations though: > > 1.) They aren't XT values, so they aren't known at compile-time > (mostly this means that they can't be used with <SWITCH structures). If they're not XTs, what are they? The can be executed, and the only thing you can execute is an XT. > > 2.) The HOF called by the parent function has to have local > variables, and it has to execute the rquotation (it can't call > another function that has local variables and that function executes > the rquotation). > > For the most part, these limitations are not a problem. Well, a library of functions like this would be a minefield. > > All in all, rquotations do everything that I really need --- just for > the sake of purity, I would rather have real quotations rather than > realish quotations --- but the realish ones are, from a practical > standpoint, adequate. I think what you mean is a closure. It's a perfectly serviceable word and saves you from making up phrases like "real quotations". > By comparison, the Paysan-faked quotations are > worse than useless --- I say "worse than useless" because they [ and it's off piste on the ski slope of insanity again ] -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-29 19:02 +0100 |
| Message-ID | <oghnh1$u2o$1@dont-email.me> |
| In reply to | #60018 |
On 5/29/2017 17:17, hughaguilar96@gmail.com wrote: >> HOFs I believe are possible in Forth with no changes, but would not >> quotations require changes to Forth? >> >> Is there even a standard way of storing locals? > How could you have HOFs without quotations??? I'd like to understand what you mean by HOF (higher order functions) and why only quotations can provide them, because the answer is, if you're using the usual meaning of the phrase -- quite easily. > > I have my rquotations working under VFX and SwiftForth. It should be > possible to implement them under any Forth compiler, but carnal > knowledge is required. It is just a matter of declaring them to be > standard --- then the carnal knowledge is hidden from the user --- > same as everything else (for example, division requires carnal > knowledge, but that doesn't prevent us from having division in the > standard). How does division require "carnal knowledge" (that is, knowledge of a specific system's internals not covered by the standard)? > > The Forth-200x committee will never accept rquotations --- the > committe is 100% committed to the Paysan-faked quotations that are > utterly useless --- Stephen Pelc wrote an article in which he said > that quotations aren't possible in Forth and so they have to be faked > (this article was the basis for the Paysan-faked quotations, and the > RfD is pretty much just the article copied word-for-word). > If I remember correctly, the XT your rquotations provided couldn't be executed outside the runtime scope of the enclosing word. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-05-29 11:06 -0700 |
| Message-ID | <fa1c07e5-1993-4763-a20d-3f26a523b458@googlegroups.com> |
| In reply to | #60018 |
> Most of the cost of the Rabbit is there because you get to use Dynamic C that only works on the Rabbit. > > If you are not going to use Dynamic C, but are going to write your own Forth, then you would be better off to buy an eZ80 from Zilog that is more powerful and costs less. I have an experimenter board for the eZ80 --- I attended a seminar at Zilog in San Jose and bought it there --- I have never really done anything with the eZ80 though, and it is in the same category as the 65c816 now (pretty much obsolete). eZ80 is pretty much dead, rabbit is not so yet. Digi has some really good and modern modules based on rabbit6000. Especially if you want ethernet and tcp/ip. Dynamic C is not standard and quite low quality in today stadards but can be just the tool for the job. Rabbit was always more popular than the eZ80. I used rabbit2000 quite a lot, in the mid 2000. I still have over 200 devices in the field with the rabbits. I was first exposed to forth due to rabbit, I was searching for Dynamic C alternatives and I found a port of a Z80 DTC eForth. I even done a real application in it, almost completely, and quite a big one. But at some point I realized that something is missing in my toolbox, and I had two variants: a PC application to deal with the source downloading (or a kind of an umbillical link) or a cross-compiler. Both was beyond my capabilities at that time and i give up. I made the application in Dynamic C, but my style was influenced by the forth experience.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-29 19:29 -0700 |
| Message-ID | <f9dd4b30-6416-4705-9d1c-3525e3077261@googlegroups.com> |
| In reply to | #60023 |
On Monday, May 29, 2017 at 11:06:50 AM UTC-7, Raimond Dragomir wrote: > > Most of the cost of the Rabbit is there because you get to use Dynamic C that only works on the Rabbit. > > > > If you are not going to use Dynamic C, but are going to write your own Forth, then you would be better off to buy an eZ80 from Zilog that is more powerful and costs less. I have an experimenter board for the eZ80 --- I attended a seminar at Zilog in San Jose and bought it there --- I have never really done anything with the eZ80 though, and it is in the same category as the 65c816 now (pretty much obsolete). > > eZ80 is pretty much dead, rabbit is not so yet. Digi has some really good > and modern modules based on rabbit6000. Especially if you want ethernet > and tcp/ip. Dynamic C is not standard and quite low quality in today > stadards but can be just the tool for the job. > > Rabbit was always more popular than the eZ80. I used rabbit2000 quite a lot, > in the mid 2000. I still have over 200 devices in the field with the > rabbits. I was first exposed to forth due to rabbit, I was searching for > Dynamic C alternatives and I found a port of a Z80 DTC eForth. I even > done a real application in it, almost completely, and quite a big one. > But at some point I realized that something is missing in my toolbox, > and I had two variants: a PC application to deal with the source downloading > (or a kind of an umbillical link) or a cross-compiler. Both was beyond > my capabilities at that time and i give up. I made the application in > Dynamic C, but my style was influenced by the forth experience. The 65c816 would be a more interesting target for Forth than the eZ80 --- both are pretty challenging as they are both funky non-orthogonal architectures --- but the 65c816, I think, is a better design. The 65c816 is also low-power and, I think, a better choice as a micro-controller. The 65c816 is an off-beat choice --- it is like Forth in that it isn't something you would want to mention on your resume --- but it is reasonable in many cases, and would be pretty fun.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-29 23:01 -0500 |
| Message-ID | <ogiqjg$682$1@dont-email.me> |
| In reply to | #60036 |
On 5/29/2017 9:29 PM, hughaguilar96@gmail.com wrote: > The 65c816 would be a more interesting target for Forth than the eZ80 --- both are pretty challenging as they are both funky non-orthogonal architectures --- but the 65c816, I think, is a better design. > > The 65c816 is also low-power and, I think, a better choice as a micro-controller. The 65c816 is an off-beat choice --- it is like Forth in that it isn't something you would want to mention on your resume --- but it is reasonable in many cases, and would be pretty fun. > In the early days of microprocessors I did not get to work with the 6502 CPUs very much, a mistake but I want to fix it, there were other weird CPUs and I played with them some but I want to try it, slow clock at the time but most instructions did not take many clocks. Most of my early work with micros were with the Intel and Motorola families I really liked the MC6809 and the MC68000. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-30 14:53 -0700 |
| Message-ID | <56f193af-1491-4677-ac08-9104c7931851@googlegroups.com> |
| In reply to | #60041 |
On Monday, May 29, 2017 at 9:01:06 PM UTC-7, Cecil - k5nwa wrote: > On 5/29/2017 9:29 PM, hughaguilar96@gmail.com wrote: > > > The 65c816 would be a more interesting target for Forth than the eZ80 --- both are pretty challenging as they are both funky non-orthogonal architectures --- but the 65c816, I think, is a better design. > > > > The 65c816 is also low-power and, I think, a better choice as a micro-controller. The 65c816 is an off-beat choice --- it is like Forth in that it isn't something you would want to mention on your resume --- but it is reasonable in many cases, and would be pretty fun. > > > In the early days of microprocessors I did not get to work with the 6502 > CPUs very much, a mistake but I want to fix it, there were other weird > CPUs and I played with them some but I want to try it, slow clock at the > time but most instructions did not take many clocks. Most of my early > work with micros were with the Intel and Motorola families I really > liked the MC6809 and the MC68000. Over on the 6502 forum there are several people who have written Forth compilers for the 65c02 or 65c816. This is the only forum I know of where Forth is discussed seriously (I don't really count comp.lang.forth because it is mostly about ANS-Forth and Forth-200x). There is a lot of enthusiasm for Forth on the 65c816 on the 6502 forum. I'm the only one who is enthusiastic for Forth on the 65c02 though, as most of the guys decided a long time ago that the 65c816 with its 16-bit registers was better for Forth. They are interested in the 65c02, of course, but they seem to mostly be interested in assembly-language on it --- nothing wrong with that! If you liked the MC68000, why don't you just upgrade to the ColdFire? The 65c816 and eZ80 are both quirky non-orthogonal 8-bit processors with a 24-bit address bus --- 20th century technology --- the 21st century is all about 32-bit micro-controllers!
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web