Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #32831 > unrolled thread
| Started by | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| First post | 2014-08-03 23:34 +0100 |
| Last post | 2014-08-08 13:40 -0700 |
| Articles | 20 on this page of 70 — 18 participants |
Back to article view | Back to comp.lang.forth
ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-03 23:34 +0100
Re: ANS Forth test programs mhx@iae.nl - 2014-08-03 22:33 -0700
Re: ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-04 08:47 +0100
Re: ANS Forth test programs "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-04 05:10 -0400
Re: ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-05 17:33 +0100
Re: ANS Forth test programs stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-21 16:01 +0000
Re: ANS Forth test programs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-21 16:20 +0000
Re: ANS Forth test programs stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-21 21:47 +0000
Re: ANS Forth test programs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-22 12:33 +0000
Re: ANS Forth test programs albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-08-22 19:23 +0000
Re: ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-22 12:28 +0100
Re: ANS Forth test programs "Alex McDonald" <blog@rivadpm.com> - 2014-08-22 13:35 +0100
Re: ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-22 17:11 +0100
Re: ANS Forth test programs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-22 12:47 +0000
Re: ANS Forth test programs Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-04 14:26 +0200
Re: ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-05 17:35 +0100
Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-05 20:06 -0700
Re: ANS Forth test programs "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-06 16:43 -0400
Re: ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-07 10:23 +0100
Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-07 18:29 -0700
Re: ANS Forth test programs "Alex McDonald" <blog@rivadpm.com> - 2014-08-07 23:28 -0700
Re: ANS Forth test programs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-08 04:25 -0500
Re: ANS Forth test programs Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-08-08 08:08 -0700
Re: ANS Forth test programs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-08 10:49 -0500
Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-08 19:54 -0700
Re: ANS Forth test programs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-08 16:27 +0000
Re: ANS Forth test programs Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-08-08 10:47 -0700
Re: ANS Forth test programs Coos Haak <chforth@hccnet.nl> - 2014-08-08 22:34 +0200
Re: ANS Forth test programs Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-08-08 21:06 -0700
Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-08 23:59 -0700
Re: ANS Forth test programs Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-08-09 01:35 -0700
Re: ANS Forth test programs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-09 04:41 -0500
Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-09 17:53 -0700
Re: ANS Forth test programs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-10 03:25 -0500
Re: ANS Forth test programs Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-08-10 03:19 -0700
Re: ANS Forth test programs Mikael Nordman <oh2aun@gmail.com> - 2014-08-10 05:28 -0700
Re: ANS Forth test programs Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-08-12 22:43 -0700
Re: ANS Forth test programs stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-13 09:46 +0000
Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-13 21:17 -0700
Re: ANS Forth test programs stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-14 10:24 +0000
Re: ANS Forth test programs "Alex McDonald" <blog@rivadpm.com> - 2014-08-14 12:10 +0100
Re: ANS Forth test programs Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-08-14 06:02 -0700
Re: ANS Forth test programs stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-14 23:48 +0000
Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-14 20:06 -0700
Re: ANS Forth test programs stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-15 09:13 +0000
Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-15 21:07 -0700
Re: ANS Forth test programs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-16 02:22 -0500
Re: ANS Forth test programs "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-16 04:43 -0400
Re: ANS Forth test programs stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-16 20:37 +0000
Re: ANS Forth test programs BruceMcF <agila61@netscape.net> - 2014-08-12 16:55 -0700
Re: ANS Forth test programs Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-08-12 22:47 -0700
Re: ANS Forth test programs "Alex McDonald" <blog@rivadpm.com> - 2014-08-13 10:43 +0100
Re: ANS Forth test programs bruce.mcfarling@gmail.com - 2014-08-16 10:02 -0700
Re: ANS Forth test programs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-09 11:09 +0000
Re: ANS Forth test programs Lars Brinkhoff <lars.spam@nocrew.org> - 2014-08-09 13:34 +0200
Re: ANS Forth test programs Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-09 21:45 +0200
Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-08 13:39 -0700
Re: ANS Forth test programs "Alex McDonald" <blog@rivadpm.com> - 2014-08-10 03:21 +0100
Re: ANS Forth test programs "Bill Leary" <Bill_Leary@msn.com> - 2014-08-08 10:34 -0400
Re: ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-08 10:18 +0100
Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-08 12:48 -0700
Re: ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-08 21:46 +0100
Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-08 14:14 -0700
Re: ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-08 23:06 +0100
Re: ANS Forth test programs Coos Haak <chforth@hccnet.nl> - 2014-08-09 00:40 +0200
Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-08 18:17 -0700
Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-06 14:50 -0700
Re: ANS Forth test programs Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-07 10:12 +0100
Re: ANS Forth test programs hughaguilar96@yahoo.com - 2014-08-07 16:07 -0700
Re: ANS Forth test programs francois.ganza@wanadoo.fr - 2014-08-08 13:40 -0700
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-08-14 12:10 +0100 |
| Message-ID | <lsi5gl$aaa$1@dont-email.me> |
| In reply to | #32931 |
on 14/08/2014 11:24:00, wrote: > On Wed, 13 Aug 2014 21:17:28 -0700 (PDT), hughaguilar96@yahoo.com > wrote: > >>WTF??? Are you saying that your cross-compiler simulates the target process= >>or at compile-time??? That is not necessary! > > Far be it from me to contradict a world authority, but you are wrong. A comment that will maintain your position in the first rank of Hugh's shit list. > Consider the case of a defining word: > >: builder create , w, c, align does> ... ; > > 1 2 3 builder builder-child > > ... builder-child ... > > What should happen in a cross compiler at > a) compile time of BUILDER > b) interpret time of BUILDER > c) interpret time of BUILDER-CHILD > and so on? At the very least the compiler needs to know > and simulate the target behaviours of: > create , w, c, align does> > > Stephen > > The Win32Forth metacompiler (yes, the target architecture is the same as the source, but that needn't be the case) avoids supporting much of anything beyond the management of the dictionary and name space. This is a simplistic approach; you can use the target CREATE , ALIGN and so on, but if you want a BUILD-CHILD in the source, then you need to explicitly code BUILDER in the metacompiler using the appropriate target CREATE , W, C, ALIGN words. (However, DOES> is excluded; it's complicated to support and its use can be avoided. Words like VALUE are meta built "by hand" rather than by using DOES>.)
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-08-14 06:02 -0700 |
| Message-ID | <a7a01b5c-7d51-434f-9217-f7efecc8bc6b@googlegroups.com> |
| In reply to | #32931 |
> > Far be it from me to contradict a world authority, but you are wrong. > > Consider the case of a defining word: > > > > : builder create , w, c, align does> ... ; > > > > 1 2 3 builder builder-child > > > > ... builder-child ... > > > > What should happen in a cross compiler at > > a) compile time of BUILDER > > b) interpret time of BUILDER > > c) interpret time of BUILDER-CHILD > > and so on? At the very least the compiler needs to know > > and simulate the target behaviours of: > > create , w, c, align does> > > > > Stephen > > > > > > -- > > Stephen Pelc, stephenXXX@mpeforth.com > > MicroProcessor Engineering Ltd - More Real, Less Time > > 133 Hill Lane, Southampton SO15 5AF, England > > tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 > > web: http://www.mpeforth.com - free VFX Forth downloads Are your cross-compiler able to compile a target forth standalone "system" that can compile to itself? Else, why do the target need words like , c, create does> ? What's the point? I thought that a cross-compiler just replace the target embedded forth compiler (and sometimes even the interpreter).
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-08-14 23:48 +0000 |
| Message-ID | <53ed4a49.224399684@news.demon.co.uk> |
| In reply to | #32933 |
On Thu, 14 Aug 2014 06:02:20 -0700 (PDT), Raimond Dragomir <raimond.dragomir@gmail.com> wrote: >Are your cross-compiler able to compile a target forth standalone "system" = >that can compile to itself? Yes, of course. We provide standalone Forths for embedded systems as well as for hosted systems. They are both built with a cross compiler. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-08-14 20:06 -0700 |
| Message-ID | <2e2a3476-c02b-4e82-87ef-4a1759bc992c@googlegroups.com> |
| In reply to | #32931 |
On Thursday, August 14, 2014 3:24:01 AM UTC-7, Stephen Pelc wrote: > On Wed, 13 Aug 2014 21:17:28 -0700 (PDT), hughaguilar96@yahoo.com > wrote: > > >WTF??? Are you saying that your cross-compiler simulates the target process= > >or at compile-time??? That is not necessary! > > Far be it from me to contradict a world authority, but you are wrong. Just to clarify --- you are saying that you believe it is necessary to simulate the execution of the target processor in order to compile to the target processor? If you are cross-compiling to a PIC24 for example, you are simulating the PIC24 execution (all of those 24-bit opcodes) on the desktop computer while cross-compiling programs for the PIC24? I'm asking you to clarify this because I find the concept to be unbelievable --- is this really what you do???
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-08-15 09:13 +0000 |
| Message-ID | <53edcb36.23349808@news.demon.co.uk> |
| In reply to | #32938 |
On Thu, 14 Aug 2014 20:06:14 -0700 (PDT), hughaguilar96@yahoo.com wrote: >On Thursday, August 14, 2014 3:24:01 AM UTC-7, Stephen Pelc wrote: >> On Wed, 13 Aug 2014 21:17:28 -0700 (PDT), hughaguilar96@yahoo.com >> wrote: >> >> >WTF??? Are you saying that your cross-compiler simulates the target process= >> >or at compile-time??? That is not necessary! >> >> Far be it from me to contradict a world authority, but you are wrong. > >Just to clarify --- you are saying that you believe it is necessary to > simulate the execution of the target processor in order to compile to >the target processor? Of course you do! Words like @ ! and friends have to be simulated. Opcode emulation is not necessary. However, in your example of a PIC24, a cross compiler has to allow for a Harvard architecture with 16 bit addess units in code space and 8 bit address units in data space. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-08-15 21:07 -0700 |
| Message-ID | <44610cf4-4001-4037-919a-f8ec61c6455b@googlegroups.com> |
| In reply to | #32939 |
On Friday, August 15, 2014 2:13:42 AM UTC-7, Stephen Pelc wrote: > On Thu, 14 Aug 2014 20:06:14 -0700 (PDT), hughaguilar96@yahoo.com > wrote: > >On Thursday, August 14, 2014 3:24:01 AM UTC-7, Stephen Pelc wrote: > >> On Wed, 13 Aug 2014 21:17:28 -0700 (PDT), hughaguilar96@yahoo.com > >> wrote: > > >> >WTF??? Are you saying that your cross-compiler simulates the target process= > >> >or at compile-time??? That is not necessary! > > >> Far be it from me to contradict a world authority, but you are wrong. > > >Just to clarify --- you are saying that you believe it is necessary to > > simulate the execution of the target processor in order to compile to > >the target processor? > > Of course you do! Words like @ ! and friends have to be simulated. > Opcode emulation is not necessary. To simulate the execution of a processor, is done by opcode emulation (typically with a CASE statements). You state that you do simulate the execution of the target processor, but that opcode emulation is not necessary. WTF??? Do you simulate the execution of the target processor or not? I asked for clarification, and you gave me two contradictory statements --- just a lot of waffle. When you say that I'm wrong, you imply that I've never written a cross-compiler and that I'm just speculating on how it is done. That isn't true; I wrote MFX. I'm not wrong --- I can tell you with certainty that it is not necessary to simulate the execution of the target processor to cross-compile code for the target processor. I did write a simulator for the MiniForth processor, but it wasn't used for compilation --- it was used to test the application program (because the MiniForth chip didn't physically exist until quite late in the project). Way back in the 1980s there was a case in which some guys were programming a 6502 board in Forth, but they were having difficulty because there wasn't enough memory for both the Forth compiler and the application program, and the 1Mhz processor ran so slowly that it took upwards of an hour to compile the program. Unfortunately, they didn't know how to write a cross-compiler. Their solution was to write a simulator for the 6502 on a minicomputer, and then run their 6502 Forth system on the simulator --- this gave them better speed, and allowed them to have the full 64K that the 6502 addresses. They called this a "cross-compiler" because it was running on a minicomputer but was generating 6502 code. The truth, of course, is that it wasn't a cross-compiler, and they still didn't know how to write a cross-compile. I don't know if this story about the 6502 "cross-compiler" that required simulating a 6502 is true or not --- it might just be an apocryphal story that C programmers like to tell for the purpose of illustrating the abysmal stupidity of Forth programmers --- but it might be true, because a lot of Forth programmers are abysmally stupid. Now, a quarter of a century later, a member of the Forth-200x committee is telling everybody on comp.lang.forth that it is necessary to simulate the execution of the target processor at compile-time to generate code for the target processor. I repeat: WTF??? > However, in your example of a > PIC24, a cross compiler has to allow for a Harvard architecture > with 16 bit addess units in code space and 8 bit address units in > data space. The PIC24 has a 24-bit address-bus for code memory, and a 16-bit address-bus for data memory. This is off-topic, because I only mentioned the PIC24 as an arbitrary example. Still though, it is annoying when you contradict me on a subject that you obviously know nothing about. I am very unimpressed with comp.lang.forth. This seems to be a forum for people to pretend to be world experts on subjects that they know nothing about. Earlier in this thread we had Alex McDonald totally baffled as to why using the data stack as the control stack is a problem, and why this requires me to hold my data in local variables in my meta-compiling words. What a moron! He obviously has never written a meta-compiling word in his life --- although I was well aware of this problem a quarter of a century ago when I was programming in Forth-83, and hoped that it would get fixed in ANS-Forth. So, as a member of the ANS-Forth committee, can you explain why the problem wasn't fixed in ANS-Forth? While you're at it, explain to Alex why this is a problem, so he can finally graduate from kindergarten --- I don't have the patience to teach such basic Forth concepts, at least, not more than the 3 or 4 times that I've already explained it on C.L.F..
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-08-16 02:22 -0500 |
| Message-ID | <ZqGdncuewOhUm3LOnZ2dnUU7-R-dnZ2d@supernews.com> |
| In reply to | #32941 |
hughaguilar96@yahoo.com wrote: > On Friday, August 15, 2014 2:13:42 AM UTC-7, Stephen Pelc wrote: >> On Thu, 14 Aug 2014 20:06:14 -0700 (PDT), hughaguilar96@yahoo.com >> wrote: >> >On Thursday, August 14, 2014 3:24:01 AM UTC-7, Stephen Pelc wrote: >> >> On Wed, 13 Aug 2014 21:17:28 -0700 (PDT), hughaguilar96@yahoo.com >> >> wrote: >> >> >> >WTF??? Are you saying that your cross-compiler simulates the target process= >> >> >or at compile-time??? That is not necessary! >> >> >> Far be it from me to contradict a world authority, but you are wrong. >> >> >Just to clarify --- you are saying that you believe it is necessary to >> > simulate the execution of the target processor in order to compile to >> >the target processor? >> >> Of course you do! Words like @ ! and friends have to be simulated. >> Opcode emulation is not necessary. > > To simulate the execution of a processor, is done by opcode > emulation (typically with a CASE statements). You state that you do > simulate the execution of the target processor, but that opcode > emulation is not necessary. Of course it isn't. If the target processor is running Forth, all you have to do is simulate it running Forth. So, you have to define @ and ! working with the correct endianness, wordsize, and so on. No-one is going to need the target assembler to generate words to use at compile time. of course, so there is absolutely no need to simulate target opcodes. > Way back in the 1980s there was a case in which some guys were > programming a 6502 board in Forth, but they were having difficulty > because there wasn't enough memory for both the Forth compiler and > the application program, and the 1Mhz processor ran so slowly that > it took upwards of an hour to compile the program. Unfortunately, > they didn't know how to write a cross-compiler. > > I don't know if this story about the 6502 "cross-compiler" that > required simulating a 6502 is true or not It doesn't take an hour to generate 64k of Forth on a 6502, so we can scratch that story. >> However, in your example of a PIC24, a cross compiler has to allow >> for a Harvard architecture with 16 bit addess units in code space >> and 8 bit address units in data space. > > The PIC24 has a 24-bit address-bus for code memory, and a 16-bit > address-bus for data memory. That is a non sequitur. > I am very unimpressed with comp.lang.forth. This seems to be a forum > for people to pretend to be world experts on subjects that they know > nothing about. Earlier in this thread we had Alex McDonald totally > baffled as to why using the data stack as the control stack is a > problem, and why this requires me to hold my data in local variables > in my meta-compiling words. Everybody is baffled as to why using the data stack as the control flow stack is a problem, and how it can require you to use local variables in metacompling words. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-08-16 04:43 -0400 |
| Message-ID | <op.xkofvf0e6zenlw@localhost> |
| In reply to | #32941 |
On Sat, 16 Aug 2014 00:07:26 -0400, <hughaguilar96@yahoo.com> wrote: > To simulate the execution of a processor, is done by opcode > emulation ... > (typically with a CASE statements). I'd say that's very common, but other methods do abound. I'm not sure it qualifies as "typically". > You state that you do simulate the execution of the target processor, > but that opcode emulation is not necessary. WTF??? Do you simulate > the execution of the target processor or not? I asked for clarification, > and you gave me two contradictory statements Yes, it's hard to follow whatever you two are babbling about ... Even so, a cross-compiler or meta-compiler, be it C or Forth, does not absolutely need to simulate the target processor. It simply generates code for a target different from the host. The intended target must execute or run the emitted code, i.e., copy it over and then run it. > --- just a lot of waffle. ... which goes good with syrup. OMG! Did I actually post that? WTF, it must be "The Hugh Effect". (Amazing, that's yet another Star Trek TNG reference in reply to Hugh by RP! Wow...) > When you say that I'm wrong, you imply that I've never written a > cross-compiler and that I'm just speculating on how it is done. > That isn't true; I wrote MFX. I'm not wrong --- I can tell you > with certainty that it is not necessary to simulate the execution > of the target processor to cross-compile code for the target processor. Logically, that does not follow. (non-sequitur) The fact that it is not necessary in your case, doesn't mean it wasn't necessary in his case. It's possible that an optimization phase is easier to implement with simulation, therefore "necessary", i.e., simpler, e.g., optimizing the timing of target code on the host would need simulation for code execution. > Earlier in this thread we had Alex McDonald totally baffled as > to why using the data stack as the control stack is a problem, > and why this requires me to hold my data in local variables in > my meta-compiling words. C does it. So, why is it a problem? ... FYI, C saves control flow and data on the same stack. This is true for the vast, vast majority of C implementations. Officially, a stack is not required by the C specifications, and isn't actually needed to implement C. It is useful to implement recursion. Yes, I'm totally baffled here as well. Are you beginning to consider that perhaps something ... is ... wrong? ... E.g., maybe what you meant to say, or thought you said in your head, and what you actually wrote means something else to everyone else? Perhaps a phrase like "in Forth" is missing, or "when using standard Forth return stack manipulation words" is missing, or "due to the push/pop nature of Forth's data stack versus the direct access typically used in C" is missing, etc. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-08-16 20:37 +0000 |
| Message-ID | <53efbfde.11647112@news.demon.co.uk> |
| In reply to | #32941 |
On Fri, 15 Aug 2014 21:07:26 -0700 (PDT), hughaguilar96@yahoo.com wrote: >To simulate the execution of a processor, is done by opcode emulation (typi= >cally with a CASE statements). Well, you are wrong again. We simulate the PIC24's implementation of Forth's words @ and ! - we do not simulate the PIC24. >When you say that I'm wrong, you imply that I've never written a cross-comp= >iler and that I'm just speculating on how it is done. Use a dictionary. I implied no such thing. You inferred it all by yourself. >> However, in your example of a >> PIC24, a cross compiler has to allow for a Harvard architecture=20 >> with 16 bit addess units in code space and 8 bit address units in >> data space.=20 > >The PIC24 has a 24-bit address-bus for code memory, and a 16-bit address-bu= >s for data memory. This is off-topic, because I only mentioned the PIC24 as= > an arbitrary example. Still though, it is annoying when you contradict me = >on a subject that you obviously know nothing about. Note that I said *nothing* about the size of the CODE address bus or the DATA address bus. What I talked about was the size of the units addressed by an address. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2014-08-12 16:55 -0700 |
| Message-ID | <9b09b45d-582f-42ae-b155-a9ecf4cbd8cf@googlegroups.com> |
| In reply to | #32894 |
On Saturday, August 9, 2014 12:06:24 AM UTC-4, Raimond Dragomir wrote: > Data space? OK. In my embedded systems I have rom and ram. Actually Flash and ram. Different spaces. It's not my choice here, or ANS or whoever else, it's the hardware. So, again, what is HERE pointing? "Data" ? What data? You mean code? Or ram space for variables and buffers? It's funny when the code is "data". It has to point to dataspace. Whether that address might also be used for codespace or namespace is up to the implementation, which is why a HERE value on the stack cannot be assumed to remain valid after : CREATE WORDLIST and other defining words unless it was reserved as dataspace by a word such as ``ALLOT'' ``,'' or ``C,''.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-08-12 22:47 -0700 |
| Message-ID | <8d8d09a5-42ff-4108-ad71-617dcb2ff7f4@googlegroups.com> |
| In reply to | #32917 |
miercuri, 13 august 2014, 02:55:55 UTC+3, BruceMcF a scris: > On Saturday, August 9, 2014 12:06:24 AM UTC-4, Raimond Dragomir wrote: > > > Data space? OK. In my embedded systems I have rom and ram. Actually Flash and ram. Different spaces. It's not my choice here, or ANS or whoever else, it's the hardware. So, again, what is HERE pointing? "Data" ? What data? You mean code? Or ram space for variables and buffers? It's funny when the code is "data". > > > > It has to point to dataspace. Whether that address might also be used for codespace or namespace is up to the implementation, which is why a HERE value on the stack cannot be assumed to remain valid after : CREATE WORDLIST and other defining words unless it was reserved as dataspace by a word such as ``ALLOT'' ``,'' or ``C,''. Even with that, in flash I cannot ALLOT and in ram I cannot , C,
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-08-13 10:43 +0100 |
| Message-ID | <lsfc0n$nsc$1@dont-email.me> |
| In reply to | #32919 |
on 13/08/2014 06:47:22, Raimond Dragomir wrote: > in flash I cannot ALLOT and in ram I cannot , C, Some flash is writable. If you mean ROM, it's the other way round. ALLOT is OK as it doesn't affect the memory space ALLOTed, but , and C, aren't as they store into the memory provided. RAM is both readable & writeable; so any of the above words work.
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-08-16 10:02 -0700 |
| Message-ID | <c6995811-4791-44b7-b787-f985ad564215@googlegroups.com> |
| In reply to | #32919 |
On Wednesday, August 13, 2014 1:47:20 AM UTC-4, Raimond Dragomir wrote: > miercuri, 13 august 2014, 02:55:55 UTC+3, BruceMcF a scris: >> On Saturday, August 9, 2014 12:06:24 AM UTC-4, Raimond Dragomir wrote: >>> Data space? OK. In my embedded systems I have rom and ram. Actually Flash and ram. Different spaces. It's not my choice here, or ANS or whoever else, it's the hardware. So, again, what is HERE pointing? "Data" ? What data? You mean code? Or ram space for variables and buffers? It's funny when the code is "data". >> It has to point to dataspace. Whether that address might also be used for codespace or namespace is up to the implementation, which is why a HERE value on the stack cannot be assumed to remain valid after : CREATE WORDLIST and other defining words unless it was reserved as dataspace by a word such as ``ALLOT'' ``,'' or ``C,''. > Even with that, in flash I cannot ALLOT and in ram I cannot , C, You might be able to ALLOT in Flash, but since you cannot do a full-featured ``,'' or ``C,'' in Flash, the point is moot. For batch-erasable, write-once memory, a specific set of capabilities are required, and in Forth94, you denote a specific set of capabilities with a set of context-appropriate names that do not overlap with Forth94 names that have a different set of capabilities. There is no reason why you could not ``,'' or ``C,'' in RAM. The issue would rather be how often that accomplishes in that setting what it normally accomplishes. The fact that you COULD use them to lay down constant components of structures on start up doesn't mean that you ever WISH to use scarce R/W memory on any task that write-once memory could be used for instead. So ``,'' and ``C,'' would be rarer in source for such a system and their Flash-analogues more common.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-08-09 11:09 +0000 |
| Message-ID | <2014Aug9.130900@mips.complang.tuwien.ac.at> |
| In reply to | #32883 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>I don't claim that forth should be write once run everywhere. As a developer of a wide range of embedded systems I know that there are things that cannot be done compatible, at least not at that low level.
>But ANS forth is too loaded with "may be this or may be that".
Sure, there are some things where I think that we could do with a
tighter specification, e.g., standardize on 2s-complement arithmentic
with wraparound on overflow. The Forth-94 committee apparently wanted
to keep the option open for implementing Forthon ones-complement and
sign-magnitude hardware, and so did not standardize 2s-complement. In
the meantime nobody has made a Forth-200x proposal on changing that,
and who knows what resistance we might see for such a proposal.
In any case, some things have not been specified tightly, for various
reasons. If you wish for a thighter specification of something, make
a concrete proposal, and you will learn about the reasons, and whether
they still outweigh the benefits of a tighter specification.
But the case of a program running on one system and crashing on
another one could be for any reason, including those that you accept.
>I think you are not serious about "here ."
Sure I am: It shows that we won't get write-once run-anywhere (in the
Java sense) in Forth (although I have good experiences with the
portability of Forth programs across platforms, including different
cell sizes and byte orders).
>But even when only "here", what is the meaning of the result? Code? Data? Dictionary header only?
|6.1.1650 HERE
|CORE
|
| ( -- addr )
|
|addr is the data-space pointer.
|
|See: 3.3.3.2 Contiguous regions.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2014-08-09 13:34 +0200 |
| Message-ID | <85oavt99s1.fsf@junk.nocrew.org> |
| In reply to | #32898 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > Sure, there are some things where I think that we could do with a > tighter specification, e.g., standardize on 2s-complement arithmentic But, but... that would make my PDP-1 port much harder!
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-08-09 21:45 +0200 |
| Message-ID | <ls5tnu$1eq$1@online.de> |
| In reply to | #32899 |
Lars Brinkhoff wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> Sure, there are some things where I think that we could do with a >> tighter specification, e.g., standardize on 2s-complement arithmentic > > But, but... that would make my PDP-1 port much harder! If you want that port to be compatible with the supposed Forth 20xx standard which drops the one's complement option, yes. But actually, would you care? The reality is that ANS Forth already makes it difficult to implement a fully compatible system that compiles to flash. That's not something weird as one's complement, since microcontrollers with embedded flash are ubiquitous, whereas there are just a few PDP-1s in the museums. The answer of the implementers are usually to avoid the cost of being fully compatible. To various degrees, some make more effort, some less. Even the systems with more effort have restrictions. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-08-08 13:39 -0700 |
| Message-ID | <a2cbbc5f-0fee-47b9-8297-28170b44978e@googlegroups.com> |
| In reply to | #32878 |
On Friday, August 8, 2014 2:25:03 AM UTC-7, Andrew Haley wrote: > Alex McDonald <blog@rivadpm.com> wrote: > > on 07/08/2014 18:29:13, huge wrote: > >> 2.) Control-flow data may have its own stack or may use the data > >> stack. > > You claim to have written a lot of Forth and to understand it better than > > most round here. > > > I wonder. I see someone struggling here with concepts that most other > > people don't seem to have an issue with. Just to take one, your point (2) > > above has necessitated "hold[ing] my working data in local variables > > rather than on the parameter stack". Why? > That one really is baffling. The novice package is intended to be understandable by novice-level programmers. Apparently you guys are below novice-level however... If you don't know what POSTPONE is, and don't know that a compile-time colon word can compile a run-time colon word (and that the run-time word may have control structures in it), then I'm not going to teach you --- I just don't have patience for adults who remain perpetually in kindergarten failing to grasp the basics of Forth --- especially when they simultaneously describe themselves as being experts on the subject. I feel like Sisyphus pushing a boulder up a hill, only to have it roll back down again every time. I mean, really --- how many times do I have to describe what :NAME does, only to discover that not a single person on comp.lang.forth has understood, and that I have to start over from the beginning again... The novice package has been available for 5 years --- if you haven't figured this stuff out by now, then you never will figure it out. When I originally wrote the novice package, I did not expect to still be explaining it 5 years later --- I really considered it to be pretty basic stuff that anybody could grasp immediately --- I expected that peole would immediately begin using it, and that it would grow primarily from user contributions --- but nobody has ever understood any of the novice package, much less been able to use it. You guys are dumber than rabbits.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-08-10 03:21 +0100 |
| Message-ID | <ls6kv3$3us$1@dont-email.me> |
| In reply to | #32885 |
on 08/08/2014 21:39:53, wrote: > On Friday, August 8, 2014 2:25:03 AM UTC-7, Andrew Haley wrote: >> Alex McDonald <blog@rivadpm.com> wrote: >> > on 07/08/2014 18:29:13, huge wrote: >> >> 2.) Control-flow data may have its own stack or may use the data >> >> stack. > >> > You claim to have written a lot of Forth and to understand it better th > an >> > most round here. >> >> > I wonder. I see someone struggling here with concepts that most other >> > people don't seem to have an issue with. Just to take one, your point ( > 2) >> > above has necessitated "hold[ing] my working data in local variables >> > rather than on the parameter stack". Why? > >> That one really is baffling. > > The novice package is intended to be understandable by novice-level > program mers. Apparently you guys are below novice-level however... > > If you don't know what POSTPONE is, and don't know that a compile-time > colo n word can compile a run-time colon word (and that the run-time > word may ha ve control structures in it), then I'm not going to teach > you --- I just do n't have patience for adults who remain perpetually > in kindergarten failing to grasp the basics of Forth --- especially > when they simultaneously descr ibe themselves as being experts on the > subject. > > I feel like Sisyphus pushing a boulder up a hill, only to have it roll > back down again every time. I mean, really --- how many times do I > have to desc ribe what :NAME does, only to discover that not a single > person on comp.lan g.forth has understood, and that I have to start > over from the beginning ag ain... The novice package has been > available for 5 years --- if you haven't figured this stuff out by > now, then you never will figure it out. When I o riginally wrote the > novice package, I did not expect to still be explaining it 5 years > later --- I really considered it to be pretty basic stuff that anybody > could grasp immediately --- I expected that peole would immediately > begin using it, and that it would grow primarily from user > contributions - You're not explaining why you are "hold[ing] my working data in local variables rather than on the parameter stack". Or even how you might do that, or need anything beyond the CS-PICK and CS-ROLL words. Variables aren't stack like, and the control flow stack is straightforward. As Andrew says, this is baffling.
[toc] | [prev] | [next] | [standalone]
| From | "Bill Leary" <Bill_Leary@msn.com> |
|---|---|
| Date | 2014-08-08 10:34 -0400 |
| Message-ID | <wL6dnSaBs6icfXnOnZ2dnUU7-R2dnZ2d@giganews.com> |
| In reply to | #32876 |
"Alex McDonald" wrote in message news:ls1qmv$n90$1@dont-email.me...
> ((..omitted..))
> I wonder. I see someone struggling here with concepts that
> most other people don't seem to have an issue with. Just to
> take one, your point (2) above has necessitated "hold[ing] my
> working data in local variables rather than on the parameter
> stack". Why?
I like Forth a lot. But I've never quite been able to cross the boundary to
being good at it. And I think this is one of the things that blocks me.
I've programmed in a lot of other languages, for a long time, and the habits
of how you think about data can be very binding. I handle Forth data
manipulation better when I use my assembler mind set, which is more stack
oriented, than my C/Basic/Pascal/what-have-you mind set. But that doesn't
help much, and probably even hurts, when dealing with Forth in general.
- Bill
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2014-08-08 10:18 +0100 |
| Message-ID | <ls24ki$d4n$1@dont-email.me> |
| In reply to | #32875 |
On 08/08/2014 02:29, hughaguilar96@yahoo.com wrote:
> On Thursday, August 7, 2014 2:23:45 AM UTC-7, Gerry wrote:
>> On 06/08/2014 04:06, hughaguilar96@yahoo.com wrote:
>>> Anyway, I don't put any stock in these test
>>> suites.
>>
>> Well if you'd tried them you *may* have known what to avoid for
>> particular systems and saved yourself time. They are very quick to run.
>
> Why should I need anything other than the ANS-Forth document to learn ANS-Forth?
The purpose of the test programs is not to teach ANS Forth (where on
earth did you get that idea) but to identify where a Forth system does
not comply with ANS Forth.
>
>> What is the point of a test suite when the ANS-Forth document repeatedly
>> says that something may be this or may be that? Is the test suite going
>> to test both forks?
>> They're contradictory!!! A program can't be both this and that --- and
>> there are multiple forks like this
>
>> Can you give an example of such forks and where a chain of them lead to
>> exponential growth, and then perhaps I can explain what the tests do.
>
> Off the top of my head, here are a few:
> 1.) Locals may have their own stack or may use the return stack.
> 2.) Control-flow data may have its own stack or may use the data stack.
> 3.) Exception frame data may have its own stack, or may use the return stack.
> 4.) Code and data may be intermixed, or may be separate.
> 5.) Names may be case-sensitive or may be case-insensitive.
> 6.) Words may have an xt or may not have an xt at all (in which case FIND aborts).
> 7.) FIND may return the same xt value for a word whether used when compiling or not compiling, or may return different xt values.
> 8.) File names may be one format, or may be another format, depending upon the OS underneath.
> 9.) Various console I/O words may corrupt the ># buffer or they may not.
> 10.) ALIGN and ALIGNED may align, or they may not do anything.
> 11.) A cell may be 16-bit, 24-bit, 32-bit, 64-bit, etc..
>
I now see where you're coming from. The test programs don't care about
those things. They are testing *what* the system does not *how* it is
implemented. Taking your first point - there isn't currently a locals
test as I've never got around to tidying my existing test up for release
with the other tests, but it would do something like this as a test:
T{ : lt1 LOCALS| a b c | b c a ; -> }T
T{ 3 2 1 lt1 -> 2 3 1 }T
where the bit before the -> is the test and the bit after is the
expected result on the data stack. The }T just checks that the 'before'
and 'after' stack values are the same. In short it is an automated
version of what you might type type in to do a simple manual test. You
tell me where tests like that depend on whether locals have their own
stack or use the return stack - it's irrelevant.
Similarly for most, if not all, the other points.
> Assuming that each of the above has 2 possibilities, that would be 2^11=2048 versions of ANS-Forth --- but several of the above have multiple possibilities,
That is not a problem for the test programs, those implementation issues
are irrelevant as I explained above.
> so we actually have tens of thousands of versions of ANS-Forth, and any program that assumes one particular version will not run on any other version.
>
> To write portable ANS-Forth code (as I did in the novice package), it is necessary to assume the worst-case scenario every time.
True, you're stating the blindingly obvious there, and sometimes it is
difficult or tedious to write a truly portable Forth program.
For example, I assume that the control-flow data is on the parameter
stack, so in my :NAME definers I hold my working data in local variables
rather than on the parameter stack. For the most part, assuming the
worst-case scenario just means assuming SwiftForth --- but not always
--- an example of Gforth being the worst-case scenario is that it
doesn't have an xt for the semicolon, which is why I have late-binding
in my MACRO: word.
>
> All in all, the ANS-Forth standard doesn't nail anything down ---
I've agreed before that a lot of legacy crap ought to be removed from
the ANS standard. To take one example, if the File-Access word set is
implemented then the Block word set, which hardly anybody uses these
days, also has to be implemented. I would remove the Block word set
entirely and release words like BLOCK and BUFFER for something useful.
But for lots of the points you raise, deciding one way or the other
would force an implementation on Forth system developers - something
that, in general they don't want.
--
Gerry
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web