Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #30165 > unrolled thread
| Started by | Laurent Laborde <kerdezixe@gmail.com> |
|---|---|
| First post | 2014-05-07 13:06 -0700 |
| Last post | 2014-05-07 20:01 -0700 |
| Articles | 20 on this page of 155 — 23 participants |
Back to article view | Back to comp.lang.forth
gforth too bloated ? Laurent Laborde <kerdezixe@gmail.com> - 2014-05-07 13:06 -0700
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-07 13:31 -0700
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-08 00:10 +0200
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-07 23:21 -0700
Re: gforth too bloated ? Laurent Laborde <kerdezixe@gmail.com> - 2014-05-08 04:07 -0700
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-08 14:21 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-09 17:36 +0000
Re: gforth too bloated ? dambere@web.de - 2014-05-09 15:01 -0700
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-10 00:05 +0200
Re: gforth too bloated ? Melzzzzz <mel@zzzzz.invalid> - 2014-05-10 00:30 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-10 09:16 +0000
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-10 03:27 +0000
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-09 20:42 -0700
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-07 22:32 -0400
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-07 21:06 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-09 04:14 -0500
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-09 13:42 -0400
Re: gforth too bloated ? Roger Levy <roger.levy@gmail.com> - 2014-05-09 11:48 -0700
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-09 15:18 -0400
Re: gforth too bloated ? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-09 09:19 -1000
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-09 15:30 -0400
Re: gforth too bloated ? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-09 13:21 -1000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-10 05:16 -0500
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-10 05:28 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-10 10:39 +0000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-10 12:04 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-11 12:10 +0000
Re: gforth too bloated ? Bill Long <blongo@gmail.com> - 2014-05-11 13:11 +0000
Re: gforth too bloated ? Stan Barr <plan.b@dsl.pipex.com> - 2014-05-11 16:17 +0000
Re: gforth too bloated ? Bill Long <blongo@gmail.com> - 2014-05-11 17:10 +0000
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-11 08:34 -0700
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-11 22:12 +0200
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-12 00:38 +0000
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-12 00:35 +0000
Re: gforth too bloated ? Howerd <howerdo@yahoo.co.uk> - 2014-05-11 23:29 -0700
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-11 23:37 -0700
Re: gforth too bloated ? Howerd <howerdo@yahoo.co.uk> - 2014-05-11 23:40 -0700
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-12 00:39 -0700
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-12 10:20 +0000
Re: gforth too bloated ? Howerd <howerdo@yahoo.co.uk> - 2014-05-12 05:10 -0700
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-13 09:17 +0000
Re: gforth too bloated ? Howerd <howerdo@yahoo.co.uk> - 2014-05-13 04:28 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-12 03:19 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-13 16:40 +0000
Re: gforth too bloated ? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-13 07:56 -1000
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-14 11:52 +0000
Re: gforth too bloated ? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-14 08:15 -1000
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-16 16:09 +0000
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-16 09:42 -0700
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-16 17:21 +0000
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-16 10:45 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-13 12:56 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-14 12:03 +0000
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-14 09:17 -0700
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-14 16:50 +0000
Re: gforth too bloated ? AKK <akk@nospam.org> - 2014-05-14 20:26 +0200
Re: gforth too bloated ? Coos Haak <chforth@hccnet.nl> - 2014-05-14 20:38 +0200
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-14 20:02 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-15 14:22 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-15 17:39 -0400
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-15 15:03 -0700
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-15 15:06 -0700
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-15 15:32 -0700
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-16 02:13 +0200
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-15 20:18 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-16 04:08 -0500
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-16 04:28 -0500
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-16 09:23 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-17 07:52 -0500
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-17 09:19 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-17 11:51 -0500
Re: gforth too bloated ? Samuel DEVULDER <samuel-dot-devulder-at-laposte-dot-net> - 2014-05-17 22:00 +0200
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-16 09:20 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-17 07:54 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-16 15:51 +0200
Re: gforth too bloated ? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-05-16 07:59 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-16 13:39 +0000
Re: gforth too bloated ? Mark Wills <markwills1970@gmail.com> - 2014-05-16 01:22 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-16 04:11 -0500
Re: gforth too bloated ? Coos Haak <chforth@hccnet.nl> - 2014-05-16 15:43 +0200
Re: gforth too bloated ? Mark Wills <markwills1970@gmail.com> - 2014-05-16 01:26 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-16 03:42 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-16 13:19 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-16 17:59 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-18 13:20 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-18 14:08 -0400
Re: gforth too bloated ? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-18 10:07 -1000
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-21 21:37 -0400
Re: gforth too bloated ? Coos Haak <chforth@hccnet.nl> - 2014-05-22 10:06 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-22 10:04 +0000
Re: gforth too bloated ? Coos Haak <chforth@hccnet.nl> - 2014-05-22 15:39 +0200
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-22 13:36 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-20 11:59 +0000
Re: gforth too bloated ? m.a.m.hendrix@tue.nl - 2014-05-20 07:11 -0700
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-20 14:48 +0000
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-21 20:27 +0000
Re: gforth too bloated ? Mark Wills <markwills1970@gmail.com> - 2014-05-22 02:23 -0700
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 14:51 +0000
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 13:41 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-21 17:41 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 14:41 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-21 17:40 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 14:16 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-17 21:09 -0400
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-15 03:57 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-15 15:50 +0200
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-15 10:07 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-16 16:33 +0000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-17 08:04 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-17 19:03 +0200
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-18 04:06 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-19 01:38 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-20 13:38 +0000
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-20 21:39 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-21 15:49 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-17 20:30 -0400
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-17 17:59 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-18 04:08 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-18 11:07 +0000
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-18 11:15 +0000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-18 12:11 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-20 12:36 +0000
Re: gforth too bloated ? m.a.m.hendrix@tue.nl - 2014-05-20 07:17 -0700
Re: gforth too bloated ? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-05-20 16:26 +0200
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-20 09:27 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-20 15:48 +0000
Re: gforth too bloated ? "Alex McDonald" <blog@rivadpm.com> - 2014-05-20 18:35 +0100
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-21 03:45 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-21 14:28 +0000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-21 11:56 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-21 20:54 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-22 14:06 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-22 17:02 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 13:05 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-23 19:19 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-22 14:30 +0000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-22 12:09 -0500
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-21 17:22 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 14:03 +0000
Re: gforth too bloated ? "Alex McDonald" <blog@rivadpm.com> - 2014-05-20 16:57 +0100
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-20 21:28 +0200
Re: gforth too bloated ? "Alex McDonald" <blog@rivadpm.com> - 2014-05-20 21:56 +0100
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-21 00:21 +0200
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-21 21:42 +0000
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-22 02:15 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 14:47 +0000
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-21 14:12 +0000
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-21 21:24 +0000
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-10 12:00 +0000
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-10 13:16 -0400
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-10 11:05 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-10 18:11 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-11 02:12 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-09 16:36 +0000
Re: gforth too bloated ? jacko <jackokring@gmail.com> - 2014-05-07 20:01 -0700
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-18 12:11 -0500 |
| Message-ID | <Jc2dndZAnotcdOXOnZ2dnUVZ_rKdnZ2d@supernews.com> |
| In reply to | #30450 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>> [Andrew Haley] >>>>>>>>I don't know anything about these tools (or why anyone would want a >>>>>>>>primitive generator) but there is at least a clue here that something >>>>>>>>might be wrong. >>>>>>> >>>>>>> Ignorance is strength? You can read about it in a number of papers, >>>>>>> including the first one on Gforth from 20 years ago [ertl93]. As to >>>>>>> what might be wrong: It's a relatively complex part of a relatively >>>>>>> complex system, and it works, so it is not that attractive for >>>>>>> tinkering. You might say that the complexity is wrong; >>>>>> >>>>>>This looks like a consequence of the desire to have a portable >>>>>>implementation based on standard tools, e.g. GCC. Which was, I think >>>>>>my original point: that the decision to write Forth-in-not-Forth leads >>>>>>to additional complexity. >>>>> >>>>> It is not a consequence of using non-Forth tools, as demonstrated by a >>>>> number of Forth systems that use non-Forth tools and don't have a >>>>> primitive generator, such as JonesForth, PFE, ThisForth etc. >>>> >>>>Why not? I didn't say it was an inevitable consequence. >>> >>> What kind of consequence do you mean then? >> >>Looking at your paper, it seems that to get good performace from Forth >>in C, you need a lot of primitives, so you need a primitive generator. > > It's more like: To get good performance from a threaded-code > implementation, you implement many words as primitives. Since we > implement every primitive only once (instead of once per > architecture), we can afford that; ok, you might say that that's a > consequence of using C, but it's not a direct consequence; moreover, a > single-architecture Forth-in-Forth-assembler implementation could > affort that, too. Perhaps, but I don't think the motivation would be as high. >>> So I gather you are missing LOCATE and VIEW. Adding them adds >>> complexity. So, IYO, should we add them to Gforth? Why, or why >>> not? >> >>Transparency is always good, and these very simple tools would make >>the system more transparent. (It is possible that adding LOCATE to >>Gforth would not be simple; I don't know.) > > Not that hard, but the traditional way (rather than Bernds > LOCATE-on-top-of-etags way) requires a header change, and that's > harder than one would wish for, because it requires changes in both > the cross-compiler and the compiler, and such changes often cause > problems in bootstrapping, and we write [ifdef]s and such to work > around that. Note that both the cross-compiler and the compiler are > written in Forth. This is troubling. Adding a cell to a header is quite a simple changes to a Forth system, or should be, IMO. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-20 12:36 +0000 |
| Message-ID | <2014May20.143604@mips.complang.tuwien.ac.at> |
| In reply to | #30452 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Looking at your paper, it seems that to get good performace from Forth
>>>in C, you need a lot of primitives, so you need a primitive generator.
>>
>> It's more like: To get good performance from a threaded-code
>> implementation, you implement many words as primitives. Since we
>> implement every primitive only once (instead of once per
>> architecture), we can afford that; ok, you might say that that's a
>> consequence of using C, but it's not a direct consequence; moreover, a
>> single-architecture Forth-in-Forth-assembler implementation could
>> affort that, too.
>
>Perhaps, but I don't think the motivation would be as high.
Why would it not?
>>>(It is possible that adding LOCATE to
>>>Gforth would not be simple; I don't know.)
>>
>> Not that hard, but the traditional way (rather than Bernds
>> LOCATE-on-top-of-etags way) requires a header change, and that's
>> harder than one would wish for, because it requires changes in both
>> the cross-compiler and the compiler, and such changes often cause
>> problems in bootstrapping, and we write [ifdef]s and such to work
>> around that. Note that both the cross-compiler and the compiler are
>> written in Forth.
>
>This is troubling. Adding a cell to a header is quite a simple
>changes to a Forth system, or should be, IMO.
Is it really? I have thought a little bit about this, and the two
aspects probably apply to most Forth systems:
1) There is a cross/meta-compiler and a compiler, so you have to do
any header change in both.
2) Bootstrapping a system with an incompatible header does incur some
risks, and when there is an error and the bootstrapping fails, you may
have to do some restoration work to get in a good state again.
I can imagine ways to deal with each of these problems (and we have
done some of that in Gforth), but the ones I have in mind increase
complexity.
Should it really be? Sure it's cute if you can do it, and Smalltalk
supposedly can do such things, but is it worth making the system more
complex in order to be able to do it? We have done only a few header
changes over the years, and it seems that other Forth systems do it
even less, so the benefit/cost ratio of adding complexity to be able
to do this does not seem favourable. Or maybe we would do it all the
time, if it was as easy as it is (suppededly) in Smalltalk.
- 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 | m.a.m.hendrix@tue.nl |
|---|---|
| Date | 2014-05-20 07:17 -0700 |
| Message-ID | <c0fae4e4-b943-4d24-ba15-d01bdf07eb06@googlegroups.com> |
| In reply to | #30474 |
On Tuesday, May 20, 2014 2:36:04 PM UTC+2, Anton Ertl wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: [..] > Should it really be? Sure it's cute if you can do it, and Smalltalk > supposedly can do such things, but is it worth making the system more > complex in order to be able to do it? We have done only a few header > changes over the years, and it seems that other Forth systems do it > even less, so the benefit/cost ratio of adding complexity to be able > to do this does not seem favourable. Or maybe we would do it all the > time, if it was as easy as it is (suppededly) in Smalltalk. Admit it, you are half-convinced already :-) Any effort on this is IMHO very well-spent. -marcel
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2014-05-20 16:26 +0200 |
| Message-ID | <85egzov84u.fsf@junk.nocrew.org> |
| In reply to | #30474 |
Anton Ertl writes: > 1) There is a cross/meta-compiler and a compiler, so you have to do > any header change in both. In my (toy) system, I have arranged for the two to share a source file with the header definition. I don't think it was very complex. > 2) Bootstrapping a system with an incompatible header does incur some > risks, and when there is an error and the bootstrapping fails, you may > have to do some restoration work to get in a good state again. I believe it's a common technique to have metacompilers generate a new system image inside a contained memory area. So if there is an error, the host image isn't corrupted.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-20 09:27 -0500 |
| Message-ID | <NIednZMTjt_---bOnZ2dnUVZ_rWdnZ2d@supernews.com> |
| In reply to | #30474 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Looking at your paper, it seems that to get good performace from Forth >>>>in C, you need a lot of primitives, so you need a primitive generator. >>> >>> It's more like: To get good performance from a threaded-code >>> implementation, you implement many words as primitives. Since we >>> implement every primitive only once (instead of once per >>> architecture), we can afford that; ok, you might say that that's a >>> consequence of using C, but it's not a direct consequence; moreover, a >>> single-architecture Forth-in-Forth-assembler implementation could >>> affort that, too. >> >>Perhaps, but I don't think the motivation would be as high. > > Why would it not? It might be a failure of imagination on my part, but even a fairly large set of core words isn't so difficult or so large that a primitive generator would be required. I can't imagine what one would be used for. Of course it's necessary for any target machine to provide either a list of primitives (for threaded code) or patterns (for a real code generator). >>>>(It is possible that adding LOCATE to >>>>Gforth would not be simple; I don't know.) >>> >>> Not that hard, but the traditional way (rather than Bernds >>> LOCATE-on-top-of-etags way) requires a header change, and that's >>> harder than one would wish for, because it requires changes in both >>> the cross-compiler and the compiler, and such changes often cause >>> problems in bootstrapping, and we write [ifdef]s and such to work >>> around that. Note that both the cross-compiler and the compiler are >>> written in Forth. >> >>This is troubling. Adding a cell to a header is quite a simple >>changes to a Forth system, or should be, IMO. > > Is it really? I have thought a little bit about this, and the two > aspects probably apply to most Forth systems: > > 1) There is a cross/meta-compiler and a compiler, so you have to do > any header change in both. Yes, I think so. > 2) Bootstrapping a system with an incompatible header does incur some > risks, and when there is an error and the bootstrapping fails, you may > have to do some restoration work to get in a good state again. I don't understand this. You have a stable Forth that is building the new Forth; the new Forth is not going to overwrite the stable Forth. What is there to restore? > I can imagine ways to deal with each of these problems (and we have > done some of that in Gforth), but the ones I have in mind increase > complexity. > > Should it really be? Sure it's cute if you can do it, and Smalltalk > supposedly can do such things, but is it worth making the system more > complex in order to be able to do it? On the contrary, making this easy to do requires the system to be simple. But yes, it's a reasonable question: is this required? I think so, based on my industrial Forth experience and that of the people I was supporting. being able to change the system was useful for real work; either for debugging and tracing or for some other reason. That was some time ago, granted. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-20 15:48 +0000 |
| Message-ID | <2014May20.174816@mips.complang.tuwien.ac.at> |
| In reply to | #30479 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> It's more like: To get good performance from a threaded-code
>>>> implementation, you implement many words as primitives. Since we
>>>> implement every primitive only once (instead of once per
>>>> architecture), we can afford that; ok, you might say that that's a
>>>> consequence of using C, but it's not a direct consequence; moreover, a
>>>> single-architecture Forth-in-Forth-assembler implementation could
>>>> affort that, too.
>>>
>>>Perhaps, but I don't think the motivation would be as high.
>>
>> Why would it not?
>
>It might be a failure of imagination on my part, but even a fairly
>large set of core words isn't so difficult or so large that a
>primitive generator would be required.
Required? No. Neither is it required when the primitives are
implemented via C.
But it would be nice if you could just write, for a threaded-code
system on, say, Alpha
+ ( n1 n2 -- n ) core plus
n1 n2 n add,
and the generator adds the loads, stores and stack pointer update
automatically from the stack effect specification, and appends the
NEXT. And then you could enhance the generator to e.g., produce
different variants of + for different input and output stack
representations (static stack caching). Just the same as we do with
C.
>> 2) Bootstrapping a system with an incompatible header does incur some
>> risks, and when there is an error and the bootstrapping fails, you may
>> have to do some restoration work to get in a good state again.
>
>I don't understand this. You have a stable Forth that is building the
>new Forth; the new Forth is not going to overwrite the stable Forth.
At some point it is. How do you call your new Forth? We call it
gforth (and the image gforth.fi). We do make a backup of the previous
version, but once there is a problem, we have to copy the backup back,
so it won't get overwritten when the next backup is made
automatically. Of course there are more advanced ways of dealing with
these backups imaginable, but they would be more complex.
Alternatively, we could call the new version something other than
gforth, and always copy manually when we think that the new version
works, but that would put more burden on the common case.
>> I can imagine ways to deal with each of these problems (and we have
>> done some of that in Gforth), but the ones I have in mind increase
>> complexity.
>>
>> Should it really be? Sure it's cute if you can do it, and Smalltalk
>> supposedly can do such things, but is it worth making the system more
>> complex in order to be able to do it?
>
>On the contrary, making this easy to do requires the system to be
>simple.
I don't see how to achieve this by making the system simpler.
>But yes, it's a reasonable question: is this required? I think so,
>based on my industrial Forth experience and that of the people I was
>supporting. being able to change the system was useful for real work;
>either for debugging and tracing or for some other reason.
I have never changed the header for these reasons, and I have done
debugging and tracing.
- 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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-05-20 18:35 +0100 |
| Message-ID | <llg3or$lj0$1@dont-email.me> |
| In reply to | #30485 |
on 20/05/2014 16:48:17, wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>> It's more like: To get good performance from a threaded-code
>>>>> implementation, you implement many words as primitives. Since we
>>>>> implement every primitive only once (instead of once per
>>>>> architecture), we can afford that; ok, you might say that that's a
>>>>> consequence of using C, but it's not a direct consequence; moreover, a
>>>>> single-architecture Forth-in-Forth-assembler implementation could
>>>>> affort that, too.
>>>>
>>>>Perhaps, but I don't think the motivation would be as high.
>>>
>>> Why would it not?
>>
>>It might be a failure of imagination on my part, but even a fairly
>>large set of core words isn't so difficult or so large that a
>>primitive generator would be required.
>
> Required? No. Neither is it required when the primitives are
> implemented via C.
>
> But it would be nice if you could just write, for a threaded-code
> system on, say, Alpha
>
> + ( n1 n2 -- n ) core plus
> n1 n2 n add,
>
> and the generator adds the loads, stores and stack pointer update
> automatically from the stack effect specification, and appends the
> NEXT. And then you could enhance the generator to e.g., produce
> different variants of + for different input and output stack
> representations (static stack caching). Just the same as we do with
> C.
>
From my unpublished W32F;
code + ( n1 n2 -- n3 ) \ add n1 to n2, return sum n3
2 1 in/out
add eax { ebp }
next; inline
I had thought of parsing the comments, but settled on the in/out as an
acceptable alternative for the moment. The 2 1 is included in the header
for + and I am using it for the SSA code generator.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-21 03:45 -0500 |
| Message-ID | <qeadnRWKeJQz-uHOnZ2dnUVZ_rKdnZ2d@supernews.com> |
| In reply to | #30485 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>> It's more like: To get good performance from a threaded-code >>>>> implementation, you implement many words as primitives. Since we >>>>> implement every primitive only once (instead of once per >>>>> architecture), we can afford that; ok, you might say that that's a >>>>> consequence of using C, but it's not a direct consequence; moreover, a >>>>> single-architecture Forth-in-Forth-assembler implementation could >>>>> affort that, too. >>>> >>>>Perhaps, but I don't think the motivation would be as high. >>> >>> Why would it not? >> >>It might be a failure of imagination on my part, but even a fairly >>large set of core words isn't so difficult or so large that a >>primitive generator would be required. > > Required? No. Neither is it required when the primitives are > implemented via C. > > But it would be nice if you could just write, for a threaded-code > system on, say, Alpha > > + ( n1 n2 -- n ) core plus > n1 n2 n add, > > and the generator adds the loads, stores and stack pointer update > automatically from the stack effect specification, and appends the > NEXT. And then you could enhance the generator to e.g., produce > different variants of + for different input and output stack > representations (static stack caching). Just the same as we do with > C. Sure, but AFAICS the complexity of the primitive generator exceeds that of just directly solving the problem without one. > Alternatively, we could call the new version something other than > gforth, and always copy manually when we think that the new version > works, but that would put more burden on the common case. Well, yes. That's what I would do every time. Recompile Forth, run the new Forth. Run some tests. >>> I can imagine ways to deal with each of these problems (and we have >>> done some of that in Gforth), but the ones I have in mind increase >>> complexity. >>> >>> Should it really be? Sure it's cute if you can do it, and Smalltalk >>> supposedly can do such things, but is it worth making the system more >>> complex in order to be able to do it? >> >>On the contrary, making this easy to do requires the system to be >>simple. > > I don't see how to achieve this by making the system simpler. Well, I didn't know why changing GForth in this way was hard to do; I was assuming it was because it was complex. That's yet to be proved, but it's a reasonable working hypothesis. >>But yes, it's a reasonable question: is this required? I think so, >>based on my industrial Forth experience and that of the people I was >>supporting. being able to change the system was useful for real work; >>either for debugging and tracing or for some other reason. > > I have never changed the header for these reasons, and I have done > debugging and tracing. Sure, but that's really not the point, but a failure of imagination. Headers are just an example. If it's easy to change a system then people will use that ability in all sorts of ways that you can't predict. So, it's not just about changing headers. It's about making the systam transparent (so that it can easily be understood) and plastic (so that it can easily be changed). It's not up to the creator of a system to say "I can't see why anyone would want to do that." Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-21 14:28 +0000 |
| Message-ID | <2014May21.162847@mips.complang.tuwien.ac.at> |
| In reply to | #30519 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>> It's more like: To get good performance from a threaded-code
>>>>>> implementation, you implement many words as primitives. Since we
>>>>>> implement every primitive only once (instead of once per
>>>>>> architecture), we can afford that; ok, you might say that that's a
>>>>>> consequence of using C, but it's not a direct consequence; moreover, a
>>>>>> single-architecture Forth-in-Forth-assembler implementation could
>>>>>> affort that, too.
>>>>>
>>>>>Perhaps, but I don't think the motivation would be as high.
>>>>
>>>> Why would it not?
>>>
>>>It might be a failure of imagination on my part, but even a fairly
>>>large set of core words isn't so difficult or so large that a
>>>primitive generator would be required.
>>
>> Required? No. Neither is it required when the primitives are
>> implemented via C.
>>
>> But it would be nice if you could just write, for a threaded-code
>> system on, say, Alpha
>>
>> + ( n1 n2 -- n ) core plus
>> n1 n2 n add,
>>
>> and the generator adds the loads, stores and stack pointer update
>> automatically from the stack effect specification, and appends the
>> NEXT. And then you could enhance the generator to e.g., produce
>> different variants of + for different input and output stack
>> representations (static stack caching). Just the same as we do with
>> C.
>
>Sure, but AFAICS the complexity of the primitive generator exceeds
>that of just directly solving the problem without one.
Maybe, but if so, the same is true if a C compiler is involved.
Overall, I am happy with the decision to write and use such a primitve
generator. The main advantages are:
*) It's a lot more engaging to write such a generator than to play
being such a generator.
*) It allowed exploration of superinstructions and stack caching to an
extent that would have required a much higher effort when coding the
whole thing manually. E.g., I tried up to 3200 static
superinstructions, and stack caching with up to 8 registers,
resulting in about 1000 primitive variants for the various stack
cache states. For stack caching I also tried variants with different
canonical states; that requires significant modfications of most
primitives. This exploration helped understand how much benefit
these optimizations provide, and what parameters to use.
>>>On the contrary, making this easy to do requires the system to be
>>>simple.
>>
>> I don't see how to achieve this by making the system simpler.
>
>Well, I didn't know why changing GForth in this way was hard to do; I
>was assuming it was because it was complex. That's yet to be proved,
>but it's a reasonable working hypothesis.
Please name a system that is simpler in this area and that does not
have the problems I discussed, and how it avoided them. If there is a
simple way to do it, I would be glad to learn about it and implement
it.
>Headers are just an example. If it's easy to change a system then
>people will use that ability in all sorts of ways that you can't
>predict.
>
>So, it's not just about changing headers. It's about making the
>systam transparent (so that it can easily be understood) and plastic
>(so that it can easily be changed). It's not up to the creator of a
>system to say "I can't see why anyone would want to do that."
Sure, it would be nice if Gforth had these qualities to a larger
extent, without having to curtail the existing qualities. I have my
doubts that plasticity can be enhanced without increasing complexity,
though.
Also, people may use plasticity in ways not imagined, or they may not
use it to the extent imagined. Knuth expected users to change TeX,
but it did not happen. I expected users to add new primitives and
superinstructions (which is easy in Gforth thanks to the primitive
generator); primitives were added by a few people, superinstructions
by very few.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-21 11:56 -0500 |
| Message-ID | <TM2dnV-8RaJcR-HOnZ2dnUVZ8qudnZ2d@supernews.com> |
| In reply to | #30522 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > Maybe, but if so, the same is true if a C compiler is involved. > > Overall, I am happy with the decision to write and use such a primitve > generator. The main advantages are: > > *) It's a lot more engaging to write such a generator than to play > being such a generator. > > *) It allowed exploration of superinstructions and stack caching to an > extent that would have required a much higher effort when coding the > whole thing manually. E.g., I tried up to 3200 static > superinstructions, and stack caching with up to 8 registers, > resulting in about 1000 primitive variants for the various stack > cache states. For stack caching I also tried variants with different > canonical states; that requires significant modfications of most > primitives. This exploration helped understand how much benefit > these optimizations provide, and what parameters to use. Ah, point taken. :-) >>>>On the contrary, making this easy to do requires the system to be >>>>simple. >>> >>> I don't see how to achieve this by making the system simpler. >> >>Well, I didn't know why changing GForth in this way was hard to do; I >>was assuming it was because it was complex. That's yet to be proved, >>but it's a reasonable working hypothesis. > > Please name a system that is simpler in this area and that does not > have the problems I discussed, and how it avoided them. If there is a > simple way to do it, I would be glad to learn about it and implement > it. I don't think it would be difficult in SwiftForth, but that's just a guess, it already has locate anyway, and I'm busy. > Also, people may use plasticity in ways not imagined, or they may not > use it to the extent imagined. Knuth expected users to change TeX, > but it did not happen. I expected users to add new primitives and > superinstructions (which is easy in Gforth thanks to the primitive > generator); primitives were added by a few people, superinstructions > by very few. I wonder if I'm misunderstanding how a primitive generator is used. In SwiftForth if I want to add a primitive I write it: icode over+ 0 [ebp] ebx add ret end-code I figured this out how to do this by LOCATEing + and then OVER . That worked, so I recompiled the kernel (which takes 150 ms!) and ran it: ~/SwiftForth/bin/linux/sfk SwiftForth i386-Linux 3.5.3 05-Feb-2014 hi hi ... and I now have a Forth with OVER+ . I didn't have to discover that a primitive generator was used, find its documentation, figure out its syntax, or anything like that. I'm sure that if you want to make hundreds of primitives, a primitive generator is the way to go, but if you just want to add one... Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-05-21 20:54 +0200 |
| Message-ID | <llispf$6bs$1@online.de> |
| In reply to | #30525 |
Andrew Haley wrote: > I didn't have to discover that a primitive generator was used, find > its documentation, figure out its syntax, or anything like that. I'm > sure that if you want to make hundreds of primitives, a primitive > generator is the way to go, but if you just want to add one... What if you tried that with Gforth? over ( w1 w2 -- w1 w2 w1 ) core + ( n1 n2 -- n ) core plus n = n1+n2; Guess: over+ ( n1 n2 -- n1 n3 ) core over_plus n3 = n1+n2; Unfortunately, the superinstruction generator is not good enough to let you simply specify over+ = over + (yeah, it's almost there ;-). What we would need to make things simpler: Automated translation of Forth names to C-compatible symbols (so that you don't have problems with over+ not being a legal C label)... The problem that it takes more than 150ms to recompile the engine is yours, Andrew, this is a GCC problem ;-). Yes, it's nice to have a Forth-in-Forth, where all these recompilations happen in the blink of an eye. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-22 14:06 +0000 |
| Message-ID | <2014May22.160627@mips.complang.tuwien.ac.at> |
| In reply to | #30530 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Unfortunately, the superinstruction generator is not good enough to let you
>simply specify
>
>over+ = over +
Superinstructions are not primitives. The are used automatically when
the sequence is seen. Therefore the name of the superinstruction is
unimportant; maybe we should leave it away and use automatically
generated names in the C code. Anyway, I can write
super32 = over +
or. if you prefer
over_plus = over +
in peeprules.vmg, then type "make" and 28s later (on my 1.65GHz AMD
E-450) I have the result. I can then run gforth-fast, and type in:
: foo over + ;
see-code foo
and it outputs
$7F4BF948CDC8 over
$7F4BF948CDD0 <0>
0x00007f4bfacf0239: add 0x8(%r15),%r14
0x00007f4bfacf023d: add $0x10,%rbp
$7F4BF948CDD8 ;s ok
And every other use of OVER + is optimized, too.
>The problem that it takes more than 150ms to recompile the engine is yours,
>Andrew, this is a GCC problem ;-).
We chose gcc for portability between architectures, and we get this
kind of portability, and the 28s is an acceptable price to pay for that.
- 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 | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-05-22 17:02 -0400 |
| Message-ID | <op.xf94q8wm6zenlw@localhost> |
| In reply to | #30564 |
On Thu, 22 May 2014 10:06:27 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Superinstructions are not primitives. Why not? ... Nobody is coding Forth using superinstructions. So, since you already know in advance what the vast majority of them are, you might as well implement most of them as primitives. Also, wouldn't implementing the superinstructions as primitives eliminate a large quantity of work for the optimizer? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-23 13:05 +0000 |
| Message-ID | <2014May23.150544@mips.complang.tuwien.ac.at> |
| In reply to | #30594 |
"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>On Thu, 22 May 2014 10:06:27 -0400, Anton Ertl
><anton@mips.complang.tuwien.ac.at> wrote:
>
>> Superinstructions are not primitives.
>
>Why not? ...
*) There is no advantage in providing them as primitives, neither to
the Forth system nor to the program. The program will get equivalent
or the same code when writing OVER + as when writing OVER+, but the
former will also port to other systems.
*) It allows removing superinstructions (and replacing them with
others, or, say with stuff used for static stack caching, or to
change the whole compilation approach to, say, an analytic compiler,
which is more effective) without breaking programs and without having
to provide replacements for the former primitives.
*) For Gforth in particular, there are technical reasons that are
discussed in [ertl&gregg03euroforth, section 4]. Note that
SwiftForth does not provide many of the superinstructions as named
primitives, either (superinstructions are called "optimizer patterns"
in SwiftForth).
@InProceedings{ertl&gregg03euroforth,
author = {M. Anton Ertl and David Gregg},
title = {Implementation Issues for Superinstructions in
{Gforth}},
booktitle = {EuroForth 2003 Conference Proceedings},
OPTpages = {},
year = {2003},
URL = {http://www.complang.tuwien.ac.at/papers/ertl%26gregg03euroforth.ps.gz},
abstract = {Combining Forth primitives into superinstructions
provides nice speedups. Several approaches to
superinstructions were explored in the Gforth
project. This paper discusses the effects of these
approaches on performance, compilation time,
implementation effort, and on programming tools such
as the decompiler and backtracing.}
}
>Nobody is coding Forth using superinstructions. So, since
>you already know in advance what the vast majority of them
>are, you might as well implement most of them as primitives.
I cannot follow you here. Why should we provide them as primitives if
nobody is using them?
>Also, wouldn't implementing the superinstructions as primitives
>eliminate a large quantity of work for the optimizer?
No. Why do you think so?
- 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 | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-05-23 19:19 -0400 |
| Message-ID | <op.xgb5rcga6zenlw@localhost> |
| In reply to | #30607 |
On Fri, 23 May 2014 09:05:44 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > "Rod Pemberton" <dont_use_email@xnothavet.cqm> writes: >> On Thu, 22 May 2014 10:06:27 -0400, Anton Ertl >> <anton@mips.complang.tuwien.ac.at> wrote: >> Nobody is coding Forth using superinstructions. So, since >> you already know in advance what the vast majority of them >> are, you might as well implement most of them as primitives. > > I cannot follow you here. Why should we provide them as > primitives if nobody is using them? There is no reason to not implement them as primitives. You know what they are, at least, the most common ones. >> Also, wouldn't implementing the superinstructions as primitives >> eliminate a large quantity of work for the optimizer? > > No. Why do you think so? > As primitives, they should already be partially compiled, e.g., implemented in assembly. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-22 14:30 +0000 |
| Message-ID | <2014May22.163011@mips.complang.tuwien.ac.at> |
| In reply to | #30525 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Well, I didn't know why changing GForth in this way was hard to do; I
>>>was assuming it was because it was complex. That's yet to be proved,
>>>but it's a reasonable working hypothesis.
>>
>> Please name a system that is simpler in this area and that does not
>> have the problems I discussed, and how it avoided them. If there is a
>> simple way to do it, I would be glad to learn about it and implement
>> it.
>
>I don't think it would be difficult in SwiftForth, but that's just a
>guess, it already has locate anyway, and I'm busy.
A static-usage counter might be an appropriate demonstration exercise.
But showing that it can be done in SwiftForth is not by itself an
answer: You would have to show that it is simpler, and explain how it
avoids the problems I mentioned above.
>> Also, people may use plasticity in ways not imagined, or they may not
>> use it to the extent imagined. Knuth expected users to change TeX,
>> but it did not happen. I expected users to add new primitives and
>> superinstructions (which is easy in Gforth thanks to the primitive
>> generator); primitives were added by a few people, superinstructions
>> by very few.
>
>I wonder if I'm misunderstanding how a primitive generator is used.
>
>In SwiftForth if I want to add a primitive I write it:
>
>icode over+ 0 [ebp] ebx add ret end-code
>
>I figured this out how to do this by LOCATEing + and then OVER .
>
>That worked, so I recompiled the kernel (which takes 150 ms!) and ran
>it:
>
>~/SwiftForth/bin/linux/sfk
>SwiftForth i386-Linux 3.5.3 05-Feb-2014
>hi hi
>...
>
>and I now have a Forth with OVER+ .
>
>I didn't have to discover that a primitive generator was used, find
>its documentation, figure out its syntax, or anything like that.
No, instead you had to discover that a word icode was used, find its
documentation, figure out it's syntax, and things like that.
Moreover, you had to find out how to recompile the kernel, to start
sfk instead of sf, and to do the magic incantation "hi hi".
For Gforth, you find OVER with M-. over RET and + with two attempts at
M-. + (it gives the wrong occurence on the first one). I think it's
at least as easy to figure out how to write OVER+ from that as for
SwiftForth, see Bernd Paysan's message. Add it in the prim file
(where you found OVER and +), then type "make" and some time later you
have a gforth with a primitive OVER+.
Anyway, I think the main reasons why people are not using the
generator more is because they can achieve what they need in other
ways, and they would have to build their own custom Gforth, and merge
their changes when the next Gforth comes out etc.
However, in SwiftForth this effort was totally pointless:
: over+ over + ; ok
see over+
8083BDF 0 [EBP] EBX ADD 035D00
8083BE2 RET C3 ok
SwiftForth already contains an optimization rule for "over +". I
looked around a little and found the code
: STACK-MATH ( n -- ) [+ASM]
( n) [EBP] EBX 0 RULEX
[-ASM] ;
: OVER-MATH 0 STACK-MATH ;
OPTIMIZE OVER + WITH OVER-MATH ASSEMBLE ADD
Maybe that's all obvious to you, but I think most people will find
stuff like
super1 = lit +
easier to understand, and will manage to write a correct
superinstruction definition like
super32 = over +
based on that (even Bernd Paysan did that successfully for other
superinstructions in the past:-).
>I'm
>sure that if you want to make hundreds of primitives, a primitive
>generator is the way to go, but if you just want to add one...
Actually most people who did write new primitives in the past wrote
many, because at that time they compensated the lack of an FFI in this
way. I think they were quite happy that they did not have to write
all the stack access code and stack pointer updates for all the calls.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-22 12:09 -0500 |
| Message-ID | <guydnS1zi9eysuPOnZ2dnUVZ8tmdnZ2d@supernews.com> |
| In reply to | #30567 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Well, I didn't know why changing GForth in this way was hard to >>>>do; I was assuming it was because it was complex. That's yet to >>>>be proved, but it's a reasonable working hypothesis. >>> >>> Please name a system that is simpler in this area and that does not >>> have the problems I discussed, and how it avoided them. If there is a >>> simple way to do it, I would be glad to learn about it and implement >>> it. >> >>I don't think it would be difficult in SwiftForth, but that's just a >>guess, it already has locate anyway, and I'm busy. > > A static-usage counter might be an appropriate demonstration exercise. > But showing that it can be done in SwiftForth is not by itself an > answer: You would have to show that it is simpler, and explain how it > avoids the problems I mentioned above. Firstly, I don't have to show how it avoids the problems you describe, because I have no experience of such problems. It's your claim that they do. Secondly, I did not claim that it was simpler than in GForth. I said that I have no idea how to do it in GForth. You claimed that adding a header field is hard. I said it should be fairly easy. >>I wonder if I'm misunderstanding how a primitive generator is used. >> >>In SwiftForth if I want to add a primitive I write it: >> >>icode over+ 0 [ebp] ebx add ret end-code >> >>I figured this out how to do this by LOCATEing + and then OVER . >> >>That worked, so I recompiled the kernel (which takes 150 ms!) and ran >>it: >> >>~/SwiftForth/bin/linux/sfk >>SwiftForth i386-Linux 3.5.3 05-Feb-2014 >>hi hi >>... >> >>and I now have a Forth with OVER+ . >> >>I didn't have to discover that a primitive generator was used, find >>its documentation, figure out its syntax, or anything like that. > > No, instead you had to discover that a word icode was used, find its > documentation, figure out it's syntax, and things like that. No, I didn't: I just used LOCATE. That immediately showed me everything I needed to know. > Moreover, you had to find out how to recompile the kernel, to start > sfk instead of sf, and to do the magic incantation "hi hi". That's true enough: I had to discover how to recompile the system. But note that it's possible to use a new primitive in a running Forth without doing that. > For Gforth, you find OVER with M-. over RET and + with two attempts at > M-. Yes, I realize that if you're prepared to leave Forth and use etags, you can do that, but it's not really the same thing, and it is very emacs-specific. > + (it gives the wrong occurence on the first one). I think it's > at least as easy to figure out how to write OVER+ from that as for > SwiftForth, see Bernd Paysan's message. Add it in the prim file > (where you found OVER and +), then type "make" and some time later you > have a gforth with a primitive OVER+. > > Anyway, I think the main reasons why people are not using the > generator more is because they can achieve what they need in other > ways, and they would have to build their own custom Gforth, and merge > their changes when the next Gforth comes out etc. > > However, in SwiftForth this effort was totally pointless: Oh for goodness' sake! OVER+ was an *example*. It was the simplest "new primitive" I could think of, and I used it precisely in order to avoid irrelevant detail which only serves to obfscate the matter at hand. The question is not whether adding this particular primitive is pointless or not, but the general question of the purpose of a primitive generator. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-05-21 17:22 -0400 |
| Message-ID | <op.xf8azskf6zenlw@localhost> |
| In reply to | #30485 |
On Tue, 20 May 2014 11:48:16 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > But it would be nice if you could just write, for a threaded-code > system on, say, Alpha > > + ( n1 n2 -- n ) core plus > n1 n2 n add, > > and the generator adds the loads, stores and stack pointer update > automatically from the stack effect specification, and appends the > NEXT. What's wrong with flex/lex and yacc/bison for this? Or, even M4? Any of them should be able to emit C or assembly. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-23 14:03 +0000 |
| Message-ID | <2014May23.160343@mips.complang.tuwien.ac.at> |
| In reply to | #30536 |
"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>On Tue, 20 May 2014 11:48:16 -0400, Anton Ertl
><anton@mips.complang.tuwien.ac.at> wrote:
>
>> But it would be nice if you could just write, for a threaded-code
>> system on, say, Alpha
>>
>> + ( n1 n2 -- n ) core plus
>> n1 n2 n add,
>>
>> and the generator adds the loads, stores and stack pointer update
>> automatically from the stack effect specification, and appends the
>> NEXT.
>
>What's wrong with flex/lex and yacc/bison for this? Or, even M4?
Flex solves scanning, Bison solves parsing, and these are rather minor
issues for the primitive generator. We do use m4 for generating
repetetive primitives, e.g., various comparison primitives.
- 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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-05-20 16:57 +0100 |
| Message-ID | <llfu0u$81a$1@dont-email.me> |
| In reply to | #30474 |
on 20/05/2014 13:36:02, wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Looking at your paper, it seems that to get good performace from Forth >>>>in C, you need a lot of primitives, so you need a primitive generator. >>> >>> It's more like: To get good performance from a threaded-code >>> implementation, you implement many words as primitives. Since we >>> implement every primitive only once (instead of once per >>> architecture), we can afford that; ok, you might say that that's a >>> consequence of using C, but it's not a direct consequence; moreover, a >>> single-architecture Forth-in-Forth-assembler implementation could >>> affort that, too. >> >>Perhaps, but I don't think the motivation would be as high. > > Why would it not? > >>>>(It is possible that adding LOCATE to >>>>Gforth would not be simple; I don't know.) >>> >>> Not that hard, but the traditional way (rather than Bernds >>> LOCATE-on-top-of-etags way) requires a header change, and that's >>> harder than one would wish for, because it requires changes in both >>> the cross-compiler and the compiler, and such changes often cause >>> problems in bootstrapping, and we write [ifdef]s and such to work >>> around that. Note that both the cross-compiler and the compiler are >>> written in Forth. >> >>This is troubling. Adding a cell to a header is quite a simple >>changes to a Forth system, or should be, IMO. > > Is it really? I have thought a little bit about this, and the two > aspects probably apply to most Forth systems: > > 1) There is a cross/meta-compiler and a compiler, so you have to do > any header change in both. Or INCLUDE at the appropriate point a single copy in both. > > 2) Bootstrapping a system with an incompatible header does incur some > risks, and when there is an error and the bootstrapping fails, you may > have to do some restoration work to get in a good state again. Yes, and my approach is to copy every time I do a metacompile, without exception. Breaking a system is all too easy, and restoration work has been, on one very frustrating occasion, a complete abandoning of a promising line of development. > > I can imagine ways to deal with each of these problems (and we have > done some of that in Gforth), but the ones I have in mind increase > complexity. > > Should it really be? Sure it's cute if you can do it, and Smalltalk > supposedly can do such things, but is it worth making the system more > complex in order to be able to do it? We have done only a few header > changes over the years, and it seems that other Forth systems do it > even less, so the benefit/cost ratio of adding complexity to be able > to do this does not seem favourable. Or maybe we would do it all the > time, if it was as easy as it is (suppededly) in Smalltalk. Or use a variable length header system, as I once proposed and had adopted for Win32Forth. I'm not sure if it's still implemented in the current versions. It had an extra cell where each bit indicated an extra cell; from 0 to (cellsize in bits) cells could follow the fixed part of the header. At a fixed cost of one cell, it was very useful for adding occasional and irregular cells, and computationally it was very simple indeed. > > - anton
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web