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 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-08-07 23:28 -0700 |
| Message-ID | <ls1qmv$n90$1@dont-email.me> |
| In reply to | #32875 |
on 07/08/2014 18:29:13, huge wrote: > >> 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 stac k. 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?
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-08-08 04:25 -0500 |
| Message-ID | <zvudnbP6wabyCnnOnZ2dnUU7-ImdnZ2d@supernews.com> |
| In reply to | #32876 |
Alex McDonald <blog@rivadpm.com> wrote: > on 07/08/2014 18:29:13, huge wrote: > >> >>> 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 stac k. > > 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. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-08-08 08:08 -0700 |
| Message-ID | <9abd98c8-b962-42c0-9091-8c0fa83b01f6@googlegroups.com> |
| In reply to | #32878 |
vineri, 8 august 2014, 12:25:03 UTC+3, Andrew Haley a scris: > Alex McDonald <blog@rivadpm.com> wrote: > > > on 07/08/2014 18:29:13, huge wrote: > > > > > >> > > >>> 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 stac k. > > > > > > 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. > > > > Andrew. That's sad how so many people in the forth community cannot understand the issues of the ANS forth standard, and like a consequence, the forth compilers/application development. All Hugh's points are common sense to me, and I'm not a compiler writer at all (not in forth). But I develop applications in forth. How can I trust any compiler vendor if they seem to not understand such issues? If I want a compiler for xxx microcontroller and I go to VFX, and then I want to go to a yyy microcontoller with SwiftX ? And discover that some things crash on one forth and work in the other and vice-versa ? How can this kind a test, that tells me that xxx forth and yyy forth are both ANS compliant, help me when one of the forth crashes? Why don't you people write a really usefull test, that will really show how different different forths will act. Like a "Crash course in ANS forth standard systems."
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-08-08 10:49 -0500 |
| Message-ID | <UpidnYVyYL4AbHnOnZ2dnUU7-eWdnZ2d@supernews.com> |
| In reply to | #32880 |
Raimond Dragomir <raimond.dragomir@gmail.com> wrote: > > That's sad how so many people in the forth community cannot > understand the issues of the ANS forth standard, and like a > consequence, the forth compilers/application development. Shrug. There are idiots everywhere. There always will be. > All Hugh's points are common sense to me, and I'm not a compiler > writer at all (not in forth). But I develop applications in forth. > > How can I trust any compiler vendor if they seem to not understand > such issues? The vendors understand perfectly well. Hugh does not. > If I want a compiler for xxx microcontroller and I go to VFX, and > then I want to go to a yyy microcontoller with SwiftX ? And discover > that some things crash on one forth and work in the other and > vice-versa ? > > How can this kind a test, that tells me that xxx forth and yyy forth > are both ANS compliant, help me when one of the forth crashes? It can't help you debug your own programs. > Why don't you people write a really usefull test, that will really > show how different different forths will act. Like a "Crash course > in ANS forth standard systems." Again, it can't help you debug your own programs. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-08-08 19:54 -0700 |
| Message-ID | <65469e32-40fa-425e-9c39-742dcbafb939@googlegroups.com> |
| In reply to | #32881 |
Here is a good one: http://memegenerator.net/instance/53401411
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-08-08 16:27 +0000 |
| Message-ID | <2014Aug8.182743@mips.complang.tuwien.ac.at> |
| In reply to | #32880 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>That's sad how so many people in the forth community cannot understand the =
>issues of the ANS forth standard, and like a consequence, the forth compile=
>rs/application development. All Hugh's points are common sense to me, and I=
>'m not a compiler writer at all (not in forth). But I develop applications =
>in forth.
>How can I trust any compiler vendor if they seem to not understand such iss=
>ues?
>If I want a compiler for xxx microcontroller and I go to VFX, and then I wa=
>nt to go to a yyy microcontoller with SwiftX ? And discover that some thing=
>s crash on one forth and work in the other and vice-versa ?
Well, then either your program has a bug or one of the compilers. The
standard specifies how systems should behave; if the compiler does not
behave as specified, then the compiler has a bug. OTOH, if you rely
on something that is not specified in the standard (say, the number of
cells in s control-flow stack item), your program has a bug. Sure,
one may want to wish for write-once-run-anywhere (the Java slogan),
but for a low-level language like Forth, you won't get it. Not even
if you run the same Forth on different platforms; e.g., "here ."
produces different results everywhere.
Jonah Thomas has once written a Forth system that was intended to test
for non-standard usage, and I have heard that Peter Knaggs is now
working on something in this vein. So if you are really keen on
checking whether your program is standard, you can try these systems.
However, I don't think Jonah Thomas' system was used much, apparently
testing the program on a few different systems is good enough.
- 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 | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-08-08 10:47 -0700 |
| Message-ID | <2621f0af-426f-4bd7-8fcc-e72909107822@googlegroups.com> |
| In reply to | #32882 |
vineri, 8 august 2014, 19:27:43 UTC+3, Anton Ertl a scris: > Raimond Dragomir <raimond.dragomir@gmail.com> writes: > > >That's sad how so many people in the forth community cannot understand the = > > >issues of the ANS forth standard, and like a consequence, the forth compile= > > >rs/application development. All Hugh's points are common sense to me, and I= > > >'m not a compiler writer at all (not in forth). But I develop applications = > > >in forth. > > >How can I trust any compiler vendor if they seem to not understand such iss= > > >ues? > > >If I want a compiler for xxx microcontroller and I go to VFX, and then I wa= > > >nt to go to a yyy microcontoller with SwiftX ? And discover that some thing= > > >s crash on one forth and work in the other and vice-versa ? > > > > Well, then either your program has a bug or one of the compilers. The > > standard specifies how systems should behave; if the compiler does not > > behave as specified, then the compiler has a bug. OTOH, if you rely > > on something that is not specified in the standard (say, the number of > > cells in s control-flow stack item), your program has a bug. Sure, > > one may want to wish for write-once-run-anywhere (the Java slogan), > > but for a low-level language like Forth, you won't get it. Not even > > if you run the same Forth on different platforms; e.g., "here ." > > produces different results everywhere. > > > > Jonah Thomas has once written a Forth system that was intended to test > > for non-standard usage, and I have heard that Peter Knaggs is now > > working on something in this vein. So if you are really keen on > > checking whether your program is standard, you can try these systems. > > However, I don't think Jonah Thomas' system was used much, apparently > > testing the program on a few different systems is good enough. > > > > - 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/ 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". I think you are not serious about "here ." But even when only "here", what is the meaning of the result? Code? Data? Dictionary header only?
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2014-08-08 22:34 +0200 |
| Message-ID | <1qwq6ueoag1x2.6w0cgov3x63n$.dlg@40tude.net> |
| In reply to | #32883 |
Op Fri, 8 Aug 2014 10:47:33 -0700 (PDT) schreef Raimond Dragomir: > vineri, 8 august 2014, 19:27:43 UTC+3, Anton Ertl a scris: >> Raimond Dragomir <raimond.dragomir@gmail.com> writes: >> >>>That's sad how so many people in the forth community cannot understand the = >> >>>issues of the ANS forth standard, and like a consequence, the forth compile= >> >>>rs/application development. All Hugh's points are common sense to me, and I= >> >>>'m not a compiler writer at all (not in forth). But I develop applications = >> >>>in forth. >> >>>How can I trust any compiler vendor if they seem to not understand such iss= >> >>>ues? >> >>>If I want a compiler for xxx microcontroller and I go to VFX, and then I wa= >> >>>nt to go to a yyy microcontoller with SwiftX ? And discover that some thing= >> >>>s crash on one forth and work in the other and vice-versa ? >> >> >> >> Well, then either your program has a bug or one of the compilers. The >> >> standard specifies how systems should behave; if the compiler does not >> >> behave as specified, then the compiler has a bug. OTOH, if you rely >> >> on something that is not specified in the standard (say, the number of >> >> cells in s control-flow stack item), your program has a bug. Sure, >> >> one may want to wish for write-once-run-anywhere (the Java slogan), >> >> but for a low-level language like Forth, you won't get it. Not even >> >> if you run the same Forth on different platforms; e.g., "here ." >> >> produces different results everywhere. >> >> >> >> Jonah Thomas has once written a Forth system that was intended to test >> >> for non-standard usage, and I have heard that Peter Knaggs is now >> >> working on something in this vein. So if you are really keen on >> >> checking whether your program is standard, you can try these systems. >> >> However, I don't think Jonah Thomas' system was used much, apparently >> >> testing the program on a few different systems is good enough. >> >> >> >> - 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/ > > 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". A compiler builder is given a lot of freedom and still can produce a standard program. The number of cells on the control-flow stack is totally irrelevant for the programmer. Read the manual that comes with your copy. > > I think you are not serious about "here ." > But even when only "here", what is the meaning of the result? Code? Data? Dictionary header only? Try for once to read the ANS/ISO documentation. It´s the data space pointer. Dictionary headers may be contiguous to data space or not, just do not assume their placement. RTFM again. -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-08-08 21:06 -0700 |
| Message-ID | <cc898e58-de37-4e14-a173-55893f33b3d4@googlegroups.com> |
| In reply to | #32887 |
vineri, 8 august 2014, 23:34:00 UTC+3, Coos Haak a scris: > Op Fri, 8 Aug 2014 10:47:33 -0700 (PDT) schreef Raimond Dragomir: > > > > > vineri, 8 august 2014, 19:27:43 UTC+3, Anton Ertl a scris: > > >> Raimond Dragomir <raimond.dragomir@gmail.com> writes: > > >> > > >>>That's sad how so many people in the forth community cannot understand the = > > >> > > >>>issues of the ANS forth standard, and like a consequence, the forth compile= > > >> > > >>>rs/application development. All Hugh's points are common sense to me, and I= > > >> > > >>>'m not a compiler writer at all (not in forth). But I develop applications = > > >> > > >>>in forth. > > >> > > >>>How can I trust any compiler vendor if they seem to not understand such iss= > > >> > > >>>ues? > > >> > > >>>If I want a compiler for xxx microcontroller and I go to VFX, and then I wa= > > >> > > >>>nt to go to a yyy microcontoller with SwiftX ? And discover that some thing= > > >> > > >>>s crash on one forth and work in the other and vice-versa ? > > >> > > >> > > >> > > >> Well, then either your program has a bug or one of the compilers. The > > >> > > >> standard specifies how systems should behave; if the compiler does not > > >> > > >> behave as specified, then the compiler has a bug. OTOH, if you rely > > >> > > >> on something that is not specified in the standard (say, the number of > > >> > > >> cells in s control-flow stack item), your program has a bug. Sure, > > >> > > >> one may want to wish for write-once-run-anywhere (the Java slogan), > > >> > > >> but for a low-level language like Forth, you won't get it. Not even > > >> > > >> if you run the same Forth on different platforms; e.g., "here ." > > >> > > >> produces different results everywhere. > > >> > > >> > > >> > > >> Jonah Thomas has once written a Forth system that was intended to test > > >> > > >> for non-standard usage, and I have heard that Peter Knaggs is now > > >> > > >> working on something in this vein. So if you are really keen on > > >> > > >> checking whether your program is standard, you can try these systems. > > >> > > >> However, I don't think Jonah Thomas' system was used much, apparently > > >> > > >> testing the program on a few different systems is good enough. > > >> > > >> > > >> > > >> - 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/ > > > > > > 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". > > A compiler builder is given a lot of freedom and still can produce a > > standard program. The number of cells on the control-flow stack is totally > > irrelevant for the programmer. Read the manual that comes with your copy. > > > > > > > > I think you are not serious about "here ." > > > But even when only "here", what is the meaning of the result? Code? Data? Dictionary header only? > > > > Try for once to read the ANS/ISO documentation. It�s the data space > > pointer. Dictionary headers may be contiguous to data space or not, just do > > not assume their placement. RTFM again. > > > > -- > > Coos > > > > CHForth, 16 bit DOS applications > > http://home.hccnet.nl/j.j.haak/forth.html 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". You don't have any clue how many times I RTFM. It's easy to send somebody to read the FM.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-08-08 23:59 -0700 |
| Message-ID | <0009206c-2d60-481e-a1d5-3b3cc0c86ccc@googlegroups.com> |
| In reply to | #32894 |
On Friday, August 8, 2014 9:06:24 PM UTC-7, Raimond Dragomir wrote: > vineri, 8 august 2014, 23:34:00 UTC+3, Coos Haak a scris: > > Op Fri, 8 Aug 2014 10:47:33 -0700 (PDT) schreef Raimond Dragomir: > > > > vineri, 8 august 2014, 19:27:43 UTC+3, Anton Ertl a scris: > > > >> Raimond Dragomir <raimond.dragomir@gmail.com> writes: > > >> if you run the same Forth on different platforms; e.g., "here ." > > >> produces different results everywhere. > > > I think you are not serious about "here ." > > > > But even when only "here", what is the meaning of the result? Code? Data? Dictionary header only? > > > Try for once to read the ANS/ISO documentation. It�s the data space > > pointer. Dictionary headers may be contiguous to data space or not, just do > > not assume their placement. RTFM again. > > 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". > > You don't have any clue how many times I RTFM. It's easy to send somebody to read the FM. HERE provides the data-space pointer (section 6.1.1650). This is the address of the next available memory in the dictionary. When you use CREATE, the value returned by HERE at this time is the address that the created variable will return when it is executed. Comma puts data into the dictionary, and it will advance the data-space pointer past that data. The problem that you are running into, is that there are a lot of other words that "may or may not" advance the data-space pointer, and this will vary from compiler to compiler --- and every one of those compilers is ANS-Forth compliant because the ANS-Forth document said that pretty much anything goes in regard to which words may or may not advance the data-space pointer. Code may or may not be intermixed with data. If it is intermixed, then anything that generates code (such as defining a colon word) will advance the data-space pointer, but otherwise won't. VARIABLE and VALUE may or may not advance the data-space pointer. Same with CONSTANT. There may be others, but I can't give you a list of which words do, because I don't know. RTFM doesn't help, because there is no list in the ANS-Forth document of all the words that advance the data-space pointer. Also, ALIGN may align or may be a no-op, so the amount that any of these words advance the data-space pointer is going to vary from one compiler to another, even if they all have the same cell-size. SwiftForth's ALIGN was a no-op in version-2, but actually aligns in version-3 (so I'm told) --- so SwiftForth-v2 will behave differently from SwiftForth-v3 even though both are 32-bit. ANS-Forth is a standard that doesn't standardize anything --- compliant compilers will behave very differently from one another. Good luck writing portable code!
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-08-09 01:35 -0700 |
| Message-ID | <8dc7b116-942e-4616-84b2-bba34f34e033@googlegroups.com> |
| In reply to | #32895 |
sâmbătă, 9 august 2014, 09:59:37 UTC+3, hughag...@yahoo.com a scris: > On Friday, August 8, 2014 9:06:24 PM UTC-7, Raimond Dragomir wrote: > > > vineri, 8 august 2014, 23:34:00 UTC+3, Coos Haak a scris: > > > > Op Fri, 8 Aug 2014 10:47:33 -0700 (PDT) schreef Raimond Dragomir: > > > > > > > > vineri, 8 august 2014, 19:27:43 UTC+3, Anton Ertl a scris: > > > > > > > >> Raimond Dragomir <raimond.dragomir@gmail.com> writes: > > > > >> if you run the same Forth on different platforms; e.g., "here ." > > > > >> produces different results everywhere. > > > > > I think you are not serious about "here ." > > > > > > > > But even when only "here", what is the meaning of the result? Code? Data? Dictionary header only? > > > > > > > Try for once to read the ANS/ISO documentation. It�s the data space > > > > pointer. Dictionary headers may be contiguous to data space or not, just do > > > > not assume their placement. RTFM again. > > > > > > 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". > > > > > > You don't have any clue how many times I RTFM. It's easy to send somebody to read the FM. > > > > HERE provides the data-space pointer (section 6.1.1650). This is the address of the next available memory in the dictionary. When you use CREATE, the value returned by HERE at this time is the address that the created variable will return when it is executed. Comma puts data into the dictionary, and it will advance the data-space pointer past that data. > > > > The problem that you are running into, is that there are a lot of other words that "may or may not" advance the data-space pointer, and this will vary from compiler to compiler --- and every one of those compilers is ANS-Forth compliant because the ANS-Forth document said that pretty much anything goes in regard to which words may or may not advance the data-space pointer. > > > > Code may or may not be intermixed with data. If it is intermixed, then anything that generates code (such as defining a colon word) will advance the data-space pointer, but otherwise won't. VARIABLE and VALUE may or may not advance the data-space pointer. Same with CONSTANT. There may be others, but I can't give you a list of which words do, because I don't know. RTFM doesn't help, because there is no list in the ANS-Forth document of all the words that advance the data-space pointer. Also, ALIGN may align or may be a no-op, so the amount that any of these words advance the data-space pointer is going to vary from one compiler to another, even if they all have the same cell-size. SwiftForth's ALIGN was a no-op in version-2, but actually aligns in version-3 (so I'm told) --- so SwiftForth-v2 will behave differently from SwiftForth-v3 even though both are 32-bit. > > > > ANS-Forth is a standard that doesn't standardize anything --- compliant compilers will behave very differently from one another. Good luck writing portable code! For desktop machines everything is in a ram memory. Even so, there may be restrictions about excutable areas or read-only areas etc. Anyway, they are less restrictive, and you may CREATE something and then you may comma something or just ALLOT something. But for really embedded systems where you have flash memory and ram memory, you doesn't compile everything in RAM. In fact, you will not compile aything in ram, you will only reserve space there. So, when I CREATE something, where I'm creating? In Flash? ok, but then I cannot ALLOT because this is meaningless. I can only comma. If I create in ram, I can allot but I can't comma. Or if I can comma (in the sense that it will be initialized r/w data) how can I create real const data (only in flash, to not waste ram space) ? So, forth is supposed to be a niche language for embedded systems. How is it supporting this kind of things? In my system I made a compromise: RAM things (variables and buffers) are always compiled by: VARIABLE HVARIABLE CVARIABLE 2VARIABLE and BUFFER: ROM things (const data in flash) are compiled only by: CREATE and all kind of comma things , c, h, ," ,c" etc My CREATE always start a ROM data definition (like the : starts a ROM executable (code) definition) where you can comma basically anything SwiftForth V2 align which doesn't aligned seems to be just a compiler bug. Even if the hardware doesn't care, ALIGN should align, because it is its function. If the forth standard permits this (I don't know) than the standard is just a toy. If it's not permitting this, then SwiftForth V2 just has a bug.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-08-09 04:41 -0500 |
| Message-ID | <dsidnSuCZrgrcXjOnZ2dnUU7-eudnZ2d@supernews.com> |
| In reply to | #32896 |
Raimond Dragomir <raimond.dragomir@gmail.com> wrote: > SwiftForth V2 align which doesn't aligned seems to be just a > compiler bug. Even if the hardware doesn't care, ALIGN should align, > because it is its function. If the forth standard permits this (I > don't know) than the standard is just a toy. If it's not permitting > this, then SwiftForth V2 just has a bug. Hardware which doesn't care has an alignment of 1. ALIGN does align on such hardware, with alignment 1. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-08-09 17:53 -0700 |
| Message-ID | <ab0a480a-e37c-4f3c-a636-8799522735a1@googlegroups.com> |
| In reply to | #32897 |
On Saturday, August 9, 2014 2:41:10 AM UTC-7, Andrew Haley wrote: > Raimond Dragomir <raimond.dragomir@gmail.com> wrote: > > > SwiftForth V2 align which doesn't aligned seems to be just a > > compiler bug. Even if the hardware doesn't care, ALIGN should align, > > because it is its function. If the forth standard permits this (I > > don't know) than the standard is just a toy. If it's not permitting > > this, then SwiftForth V2 just has a bug. > Hardware which doesn't care has an alignment of 1. ALIGN does align > on such hardware, with alignment 1. This is so much baloney! The concept of alignment has always meant alignment to the cell size (register size). The only processors that have an alignment of 1 are the 8-bit processors such as the 65c02 and Z80 that have 1-byte registers and an 8-bit data-bus. The concept that the hardware will "care" is meaningless, because hardware isn't sentient. On some processors (the MC68000), accessing an unaligned address will cause an exception --- it just isn't allowed. On some processors (the x86), accessing an unaligned address will work inefficiently. This is extremely inefficient on the 16-bit x86 (except the 8088 that has an 8-bit data-bus), but doesn't really matter that much on the later processors (so long as you are not overlapping cache-lines, there shouldn't be any inefficiency). So, on the 80486 the hardware does "care," but on the modern x86 the hardware doesn't "care" --- so, by Andrew's "thinking," the definition of alignment changes even though it is the same program being executed in both cases! --- we have to put the computer on a psychologist's couch and inquire into the computer's feelings... Anyway, anybody who knows even a little bit of assembly-language should know this stuff --- when SwiftForth failed to implement ALIGN and ALIGNED properly, this indicated an almost complete lack of knowledge of assembly-language --- when ANS-Forth (3.3.3.1.) failed to define "alignment" in its section on alignment, this indicated purposeful vagueness typical of salespeople who are covering up the fact that they don't know what the technical terms they are using mean.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-08-10 03:25 -0500 |
| Message-ID | <f82dnb2dG5P7sXrOnZ2dnUU7-WudnZ2d@supernews.com> |
| In reply to | #32901 |
hughaguilar96@yahoo.com wrote: > On Saturday, August 9, 2014 2:41:10 AM UTC-7, Andrew Haley wrote: >> Raimond Dragomir <raimond.dragomir@gmail.com> wrote: >> >> > SwiftForth V2 align which doesn't aligned seems to be just a >> > compiler bug. Even if the hardware doesn't care, ALIGN should align, >> > because it is its function. If the forth standard permits this (I >> > don't know) than the standard is just a toy. If it's not permitting >> > this, then SwiftForth V2 just has a bug. > >> Hardware which doesn't care has an alignment of 1. ALIGN does align >> on such hardware, with alignment 1. > > This is so much baloney! The concept of alignment has always meant > alignment to the cell size (register size). Actually, no. In the past there was no need to align to the cell size on many processors. Then came processors which required strict alignment and some which were faster with aligned cells. With the fomer, ALIGN must cell-align, and with the latter it's an implementation decision. > The only processors that have an alignment of 1 are the 8-bit > processors such as the 65c02 and Z80 that have 1-byte registers and > an 8-bit data-bus. So, 1-aligning is a sensible choice on such parts. > On some processors (the x86), accessing an unaligned address will > work inefficiently. This is extremely inefficient on the 16-bit x86 > (except the 8088 that has an 8-bit data-bus), but doesn't really > matter that much on the later processors (so long as you are not > overlapping cache-lines, there shouldn't be any inefficiency). So, > on the 80486 the hardware does "care," but on the modern x86 the > hardware doesn't "care" That's right: unless a cell in memory straddles a cache line it makes no difference. However, when it does straddle a cache line there is a penalty. For that reason I'd align cells in structs on modern x86 hardware. So, in summary: my statment, which was >> Hardware which doesn't care has an alignment of 1. ALIGN does align >> on such hardware, with alignment 1. is entirely true. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-08-10 03:19 -0700 |
| Message-ID | <b1a586da-9ffa-4286-aad0-e7f97ed67306@googlegroups.com> |
| In reply to | #32903 |
duminică, 10 august 2014, 11:25:10 UTC+3, Andrew Haley a scris: > hughaguilar96@yahoo.com wrote: > > > On Saturday, August 9, 2014 2:41:10 AM UTC-7, Andrew Haley wrote: > > >> Raimond Dragomir <raimond.dragomir@gmail.com> wrote: > > >> > > >> > SwiftForth V2 align which doesn't aligned seems to be just a > > >> > compiler bug. Even if the hardware doesn't care, ALIGN should align, > > >> > because it is its function. If the forth standard permits this (I > > >> > don't know) than the standard is just a toy. If it's not permitting > > >> > this, then SwiftForth V2 just has a bug. > > > > > >> Hardware which doesn't care has an alignment of 1. ALIGN does align > > >> on such hardware, with alignment 1. > > > > > > This is so much baloney! The concept of alignment has always meant > > > alignment to the cell size (register size). > > > > Actually, no. In the past there was no need to align to the cell size > > on many processors. Then came processors which required strict > > alignment and some which were faster with aligned cells. With the > > fomer, ALIGN must cell-align, and with the latter it's an > > implementation decision. > > > > > The only processors that have an alignment of 1 are the 8-bit > > > processors such as the 65c02 and Z80 that have 1-byte registers and > > > an 8-bit data-bus. > > > > So, 1-aligning is a sensible choice on such parts. > > > > > On some processors (the x86), accessing an unaligned address will > > > work inefficiently. This is extremely inefficient on the 16-bit x86 > > > (except the 8088 that has an 8-bit data-bus), but doesn't really > > > matter that much on the later processors (so long as you are not > > > overlapping cache-lines, there shouldn't be any inefficiency). So, > > > on the 80486 the hardware does "care," but on the modern x86 the > > > hardware doesn't "care" > > > > That's right: unless a cell in memory straddles a cache line it makes > > no difference. However, when it does straddle a cache line there is a > > penalty. For that reason I'd align cells in structs on modern x86 > > hardware. > > > > So, in summary: my statment, which was > > > > >> Hardware which doesn't care has an alignment of 1. ALIGN does align > > >> on such hardware, with alignment 1. > > > > is entirely true. > > > > Andrew. In my view, aligning is a clear concept. Usually the boundary is explicit. When not, it is some default, like cell size, register size or just 1 (no aligning). Personally I thought that the forth align is on the forth cell size. It seems not, at least by the ans standard.
[toc] | [prev] | [next] | [standalone]
| From | Mikael Nordman <oh2aun@gmail.com> |
|---|---|
| Date | 2014-08-10 05:28 -0700 |
| Message-ID | <161a29c8-6938-44a9-838b-94593e8213b1@googlegroups.com> |
| In reply to | #32896 |
On Saturday, August 9, 2014 11:35:50 AM UTC+3, Raimond Dragomir wrote: > But for really embedded systems where you have flash memory and ram memory, you doesn't compile everything in RAM. In fact, you will not compile aything in ram, you will only reserve space there. > So, when I CREATE something, where I'm creating? In Flash? ok, but then I cannot ALLOT because this is meaningless. I can only comma. If I create in ram, I can allot but I can't comma. Or if I can comma (in the sense that it will be initialized r/w data) how can I create real const data (only in flash, to not waste ram space) ? > So, forth is supposed to be a niche language for embedded systems. How is it supporting this kind of things? > In my FlashForth I have flash, eeprom and ram as data space. So you can do FLASH CREATE ALLOT DOES> EEPROM CREATE ALLOT DOES> RAM CREATE ALLOT DOES> The system has separate data space pointers for each type of memory. There is also a current data space pointer that is set by FLASH, EEPROM, RAM. It also has three way memory operators that based on the address range can decide which read write code to use. Like this FlashForth handles symmetrically all kinds of memories. Flash and eeprom are considered modifiable memory. Writing to flash is done via buffer that has the size of a flash erase unit. It then falls on the programmer to write code that does not modify flash or eeprom in a loop. To help with that there words the disable/enable writes to flash and eeprom. Mike http://flashforth.sourceforge.net
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-08-12 22:43 -0700 |
| Message-ID | <6338ab10-796c-47dd-961e-8f6f728b34f1@googlegroups.com> |
| In reply to | #32905 |
duminică, 10 august 2014, 15:28:15 UTC+3, Mikael Nordman a scris: > On Saturday, August 9, 2014 11:35:50 AM UTC+3, Raimond Dragomir wrote: > > > But for really embedded systems where you have flash memory and ram memory, you doesn't compile everything in RAM. In fact, you will not compile aything in ram, you will only reserve space there. > > > So, when I CREATE something, where I'm creating? In Flash? ok, but then I cannot ALLOT because this is meaningless. I can only comma. If I create in ram, I can allot but I can't comma. Or if I can comma (in the sense that it will be initialized r/w data) how can I create real const data (only in flash, to not waste ram space) ? > > > So, forth is supposed to be a niche language for embedded systems. How is it supporting this kind of things? > > > > > > > In my FlashForth I have flash, eeprom and ram as data space. > > So you can do > > FLASH CREATE ALLOT DOES> > > EEPROM CREATE ALLOT DOES> > > RAM CREATE ALLOT DOES> > > > > The system has separate data space pointers for each type of memory. > > There is also a current data space pointer that is set by FLASH, EEPROM, RAM. > > It also has three way memory operators that based on the address range can decide which read write code to use. > > > > Like this FlashForth handles symmetrically all kinds of memories. > > Flash and eeprom are considered modifiable memory. > > Writing to flash is done via buffer that has the size of a flash erase unit. > > > > It then falls on the programmer to write code that does not modify flash or eeprom in a loop. To help with that there words the disable/enable writes to flash and eeprom. > > > > Mike > > http://flashforth.sourceforge.net I also have RAM and ROM words to help in choosing the space, even though many words will set the space automatically. In an AVR implementation I even had EEPROM space. But all this is not "standard". For example, you have FLASH, I have ROM :) I don't suppose the standard to have all I'm needing, but the lack of these "space" support at least is not encouraging. There is even some document regarding cross-compilation, but seems that nobody take it seriously. It's sad because embedded systems and cross-compilation are a good niche for the forth language.
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-08-13 09:46 +0000 |
| Message-ID | <53eb2aec.85298507@news.demon.co.uk> |
| In reply to | #32918 |
On Tue, 12 Aug 2014 22:43:48 -0700 (PDT), Raimond Dragomir <raimond.dragomir@gmail.com> wrote: >I don't suppose the standard to have all I'm needing, but the lack of these= > "space" support at least is not encouraging. There is even some document r= >egarding cross-compilation, but seems that nobody take it seriously. It's s= >ad because embedded systems and cross-compilation are a good niche for the = >forth language. There's not much discussion of it because it was formulated and implemented in the 1990s by Forth Inc and MPE for a project that we were both working on. The notation has survived essentially unchanged in our cross compilers since then. 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-13 21:17 -0700 |
| Message-ID | <cf1379ea-3034-4d2f-bb87-ddff06e1a890@googlegroups.com> |
| In reply to | #32921 |
On Wednesday, August 13, 2014 2:46:57 AM UTC-7, Stephen Pelc wrote: > There's not much discussion of it because it was formulated and > implemented in the 1990s by Forth Inc and MPE for a project that > we were both working on. > > The notation has survived essentially unchanged in our cross > compilers since then. I haven't read the Forth-200x document on cross-compilers, and I don't intend to, as Jeff Fox told me that it was over-complicated and not worth reading --- I think that I already know everything there is to know about Forth cross-compilation from my personal experience writing MFX. In this thread, https://groups.google.com/forum/#!searchin/comp.lang.forth/LC53%7Csort:relevance/comp.lang.forth/wP5nw1ClzsM/E-TV9v2y9RoJ You said this: On Tuesday, December 8, 2009 3:18:13 PM UTC-7, Stephen Pelc wrote: > There are three types of compilation involved > 1) Host compilation > 2) Clone compilation (target CPU same as host and memory matches) > 3) Cross compilation (target CPU is not host CPU) > > In the third case you have to simulate *everything* when dealing > with both the definition and execution of defining words. It's not > easy. You also have to extend the normal Forth compiler by at least > two time frames. Forth cross compilers are much more complicated > and much more subtle than they appear to be. WTF??? Are you saying that your cross-compiler simulates the target processor at compile-time??? That is not necessary!
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-08-14 10:24 +0000 |
| Message-ID | <53ec8c47.175756872@news.demon.co.uk> |
| In reply to | #32928 |
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. 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
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web