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 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-05-13 09:17 +0000 |
| Message-ID | <5371e341$0$27136$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #30316 |
In article <d663ecd2-a269-411d-b26b-f7541e4c69cc@googlegroups.com>, Howerd <howerdo@yahoo.co.uk> wrote: >Hi Albert, > >> I intended to use ran, not run. Past tense. >>(This mistake comes about because I'm not a native speaker.) >Uw Engels is veel beter dan mijn Nederlands, zelfs met de hulp van >Google Translate ;-) > >> Surely you've done some work and don't use Chuck's colorforth as is. >Sort of - the colorForth kernel that I distribute is assembled using >NASM from sources created by several people, including the late Terry >Loveall, who fixed the floppy driver in Chuck's original - that mod is >now in Chuck's version too. What I have done is collect together the >source files in NASM format that produce an almost identical binary to >the color.com on Chuck's website. The differences are mostly due to NASM >and MASM ( IIRC ) assembling different code. I tried to go that same route. But I created a color.com that is an exact copy using a Forth tool I made, ciasdis, except for the memory area's that where unitialized. [The late Jeff Fox ridiculed those efforts, I never really understood why. ] There it stopped because I couldn't test it. Later someone came up with a booting emulator, and it does run under that. > >> That was the colorforth I commented about. >The kernel is functionally identical, I believe. <SNIP> > >Best regards, >Howerd > > Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Howerd <howerdo@yahoo.co.uk> |
|---|---|
| Date | 2014-05-13 04:28 -0700 |
| Message-ID | <87547c06-3f36-44b1-9341-953f88719c91@googlegroups.com> |
| In reply to | #30325 |
Hi Albert, > I tried to go that same route. But I created a color.com that is an > exact copy using a Forth tool I made, ciasdis, except for the memory > area's that where unitialized. Yes - there are some variables in the middle of the executable. > [The late Jeff Fox ridiculed those efforts, I never really understood why. ] Probably a reflex action - Jeff got attacked a lot for his beliefs. > There it stopped because I couldn't test it. Later someone came up with a > booting emulator, and it does run under that. I used DosBox ( or a command window in WinXP, or DOS ) and a 32 bit version of DEBUG called GRDB ( Get Real Debugger ) - not a nice environment compared to Forth, but it is usable. I got stuck on the use of the stacks and interrupts in 16 and 32 bit mode, and changing between them to access 16 bit BIOS calls. Not easy stuff to debug, but John Commeaus's version works. You would think it would be easy to merge it with mine, but it is not. Maybe we could collaborate on this? I have scheduled some time for colorForth after I retire, and before I die, but this may be a negative or zero quantity. Actually, it only makes sense financially if I retire at least 10 years after death... ;-) Maybe I can shift my priorities around a little... Best regards, Howerd On Tuesday, 13 May 2014 10:17:53 UTC+1, Albert van der Horst wrote: > In article <....@googlegroups.com>, > > Howerd <h...@yahoo.co.uk> wrote: > > >Hi Albert, > > > > > >> I intended to use ran, not run. Past tense. > > >>(This mistake comes about because I'm not a native speaker.) > > >Uw Engels is veel beter dan mijn Nederlands, zelfs met de hulp van > > >Google Translate ;-) > > > > > >> Surely you've done some work and don't use Chuck's colorforth as is. > > >Sort of - the colorForth kernel that I distribute is assembled using > > >NASM from sources created by several people, including the late Terry > > >Loveall, who fixed the floppy driver in Chuck's original - that mod is > > >now in Chuck's version too. What I have done is collect together the > > >source files in NASM format that produce an almost identical binary to > > >the color.com on Chuck's website. The differences are mostly due to NASM > > >and MASM ( IIRC ) assembling different code. > > > > I tried to go that same route. But I created a color.com that is an > > exact copy using a Forth tool I made, ciasdis, except for the memory > > area's that where unitialized. > > [The late Jeff Fox ridiculed those efforts, I never really understood why. ] > > There it stopped because I couldn't test it. Later someone came up with a > > booting emulator, and it does run under that. > > > > > > > >> That was the colorforth I commented about. > > >The kernel is functionally identical, I believe. > > > > <SNIP> > > > > > > > >Best regards, > > >Howerd > > > > > > > > Groetjes Albert > > -- > > Albert van der Horst, UTRECHT,THE NETHERLANDS > > Economic growth -- being exponential -- ultimately falters. > > albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-12 03:19 -0500 |
| Message-ID | <kv2dnZxzlai0Ge3OnZ2dnUVZ_hidnZ2d@supernews.com> |
| In reply to | #30288 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> The alternative is to go the Chuck Moore way: No OS, no software from >>> anyone else, just a bare Forth on the bare hardware. >> >>Right, and I have had the great pleasure of using such systems. But >>these days the complexity of the hardware and the usefulness of system >>libraries means a truly standalone Forth is less useful. > > And the bare-hardware approach also has it's risks. When we started > Gforth, we were working on DecStations (little-endian MIPS > architecture) and HPPA machines. HPPA is dead, and MIPS has retreated > to some niches in the embedded market (and little-endian MIPS is no > longer used AFAIK). But so what? You just write another back end; surely a Forth back end doesn't have to be a huge job. (In comparison: I'm just at the end of porting Java to a new processor, and that really is a huge job: some 3-4 programmer years.) > The rest of the hardware of these machines died even sooner, and in > any case, hardly anybody would boot such a machine into a bare-metal > mode to run a Forth system. Of course: that's the audience for such machines. >>But this doesn't reduce the advantage of Forth-in-Forth, of course. > > For simple systems like eForth, yes. For complex ones like Gforth, > I have my doubts. E.g., the primitive generator prims2x.fs is > written in Forth , but I don't have the impression that this has > inspired anyone to tinker with it. The cross-compiler is also > written in Forth, and even I don't touch it (and avoid dealing with > it if I can). 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. Forth cross compilers are inevitably more fiddly than native compilers, but they don't have to be very complex. The kind of radical simplicity practiced (and preached) by Chuck Moore requires a tremendous amount of discipline, more than most of us are always capable of, and sometimes we fail. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-13 16:40 +0000 |
| Message-ID | <2014May13.184005@mips.complang.tuwien.ac.at> |
| In reply to | #30311 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> And the bare-hardware approach also has it's risks. When we started
>> Gforth, we were working on DecStations (little-endian MIPS
>> architecture) and HPPA machines. HPPA is dead, and MIPS has retreated
>> to some niches in the embedded market (and little-endian MIPS is no
>> longer used AFAIK).
>
>But so what? You just write another back end; surely a Forth back end
>doesn't have to be a huge job.
Maybe. But somehow the masses of ports of Forth-in-Forth systems to
all kinds of machines don't happen. In the server/workstation area
not at all, somewhat more in the small systems areas, but even there
the systems typically only support a few targets and that's it.
>(In comparison: I'm just at the end of
>porting Java to a new processor, and that really is a huge job: some
>3-4 programmer years.)
That's probably more a function of the budget and the performance
goals you have than of the language.
>>>But this doesn't reduce the advantage of Forth-in-Forth, of course.
>>
>> For simple systems like eForth, yes. For complex ones like Gforth,
>> I have my doubts. E.g., the primitive generator prims2x.fs is
>> written in Forth , but I don't have the impression that this has
>> inspired anyone to tinker with it. The cross-compiler is also
>> written in Forth, and even I don't touch it (and avoid dealing with
>> it if I can).
>
>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; in that case
you are free to use any of the systems that value simplicity over
Gforth's goals, say colorForth.
@InProceedings{ertl93,
author = "M. Anton Ertl",
title = "A Portable {Forth} Engine",
booktitle = "EuroFORTH '93 conference proceedings",
year = "1993",
address = "Mari\'ansk\'e L\'azn\`e (Marienbad)",
url = "http://www.complang.tuwien.ac.at/papers/ertl93.ps.gz",
abstract = "The Forth engine discussed in this paper is written
in GNU C, which provides several extensions that are
important for Forth implementation. The indirect
threaded Forth engine is completely
machine-independent, direct threading requires a few
machine-specific lines for each machine. Using
a portable language like GNU C encourages producing
an engine with many primitives. In order to make the
development of primitives easier and less
error-prone, an automatic tool generates most of the
code for a Forth primitive from the stack effect
notation, even if the TOS is kept in a register. The
engine is combined with the parts of the system
written in Forth by loading a machine-independent
image file that contains the executable Forth code
in relocatable form."
}
>Forth cross compilers are inevitably more fiddly than
>native compilers, but they don't have to be very complex.
I don't think it's very complex, but it's hardly documented, and I
typically have something higher on the agenda than playing around with
it.
- 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-05-13 07:56 -1000 |
| Message-ID | <vOqdnSltB9Qkwe_OnZ2dnUVZ_gudnZ2d@supernews.com> |
| In reply to | #30337 |
On 5/13/14 6:40 AM, Anton Ertl wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> And the bare-hardware approach also has it's risks. When we started >>> Gforth, we were working on DecStations (little-endian MIPS >>> architecture) and HPPA machines. HPPA is dead, and MIPS has retreated >>> to some niches in the embedded market (and little-endian MIPS is no >>> longer used AFAIK). >> >> But so what? You just write another back end; surely a Forth back end >> doesn't have to be a huge job. > > Maybe. But somehow the masses of ports of Forth-in-Forth systems to > all kinds of machines don't happen. In the server/workstation area > not at all, somewhat more in the small systems areas, but even there > the systems typically only support a few targets and that's it. Who sez? FORTH, Inc. has supported over 40 different processors plus variants over our history using Forth-in-Forth. >> (In comparison: I'm just at the end of >> porting Java to a new processor, and that really is a huge job: some >> 3-4 programmer years.) > > That's probably more a function of the budget and the performance > goals you have than of the language. It typically takes a few weeks (2-4) to deal with a new processor plus drivers, etc., and including fairly serious performance goals. ... >> Forth cross compilers are inevitably more fiddly than >> native compilers, but they don't have to be very complex. > > I don't think it's very complex, but it's hardly documented, and I > typically have something higher on the agenda than playing around with > it. I do like to think SwiftX's cross-compiler is pretty well documented, and the general principles are discussed in the Cross Compiler papers whose links I have posted from time to time. Cheers, Ellizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-14 11:52 +0000 |
| Message-ID | <2014May14.135252@mips.complang.tuwien.ac.at> |
| In reply to | #30339 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 5/13/14 6:40 AM, Anton Ertl wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> But so what? You just write another back end; surely a Forth back end
>>> doesn't have to be a huge job.
>>
>> Maybe. But somehow the masses of ports of Forth-in-Forth systems to
>> all kinds of machines don't happen. In the server/workstation area
>> not at all, somewhat more in the small systems areas, but even there
>> the systems typically only support a few targets and that's it.
>
>Who sez? FORTH, Inc. has supported over 40 different processors plus
>variants over our history using Forth-in-Forth.
Sure, over your history. Do you support all of them now? If not, why
not? How many do you support now?
AMD64 became available 11 years ago, and Gforth supported it right
away. Of the Forths-in-Forth, lina took five years to support AMD64,
iForth took 6 (and stopped further IA-32 releases at the same time),
and SwiftForth, VFX and bigForth still don't support it 11 years
later. It seems that, while retargeting is theoretically easy, in
practice it's hard enough that it rarely happens.
- 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-05-14 08:15 -1000 |
| Message-ID | <xcKdnRJyX6hKL-7OnZ2dnUVZ_uednZ2d@supernews.com> |
| In reply to | #30366 |
On 5/14/14 1:52 AM, Anton Ertl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> On 5/13/14 6:40 AM, Anton Ertl wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>> But so what? You just write another back end; surely a Forth back end >>>> doesn't have to be a huge job. >>> >>> Maybe. But somehow the masses of ports of Forth-in-Forth systems to >>> all kinds of machines don't happen. In the server/workstation area >>> not at all, somewhat more in the small systems areas, but even there >>> the systems typically only support a few targets and that's it. >> >> Who sez? FORTH, Inc. has supported over 40 different processors plus >> variants over our history using Forth-in-Forth. > > Sure, over your history. Do you support all of them now? If not, why > not? How many do you support now? > > AMD64 became available 11 years ago, and Gforth supported it right > away. Of the Forths-in-Forth, lina took five years to support AMD64, > iForth took 6 (and stopped further IA-32 releases at the same time), > and SwiftForth, VFX and bigForth still don't support it 11 years > later. It seems that, while retargeting is theoretically easy, in > practice it's hard enough that it rarely happens. Well, we support platforms based on demand from customers. As folks who rely customers to support us, we have to! SwiftForth is available for 3 OSs (Windows, Linux, Mac) and SwiftX currently supports 10 microcontroller families (ARM. Coldfire, MSP430, AVR, 68HCS08, 68K, 68HC12, 68HC11, 8051, i386, 69R000, and RTX2010. Although we no longer support some platforms such as the PDP-11, Nova, General Automation, Modcomp, and Z80, we could revive those systems pretty easily if someone came along with a need and a budget. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-16 16:09 +0000 |
| Message-ID | <2014May16.180948@mips.complang.tuwien.ac.at> |
| In reply to | #30381 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 5/14/14 1:52 AM, Anton Ertl wrote:
>> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> On 5/13/14 6:40 AM, Anton Ertl wrote:
>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>> But so what? You just write another back end; surely a Forth back end
>>>>> doesn't have to be a huge job.
...
>> AMD64 became available 11 years ago, and Gforth supported it right
>> away. Of the Forths-in-Forth, lina took five years to support AMD64,
>> iForth took 6 (and stopped further IA-32 releases at the same time),
>> and SwiftForth, VFX and bigForth still don't support it 11 years
>> later. It seems that, while retargeting is theoretically easy, in
>> practice it's hard enough that it rarely happens.
>
>Well, we support platforms based on demand from customers. As folks who
>rely customers to support us, we have to! SwiftForth is available for 3
>OSs (Windows, Linux, Mac) and SwiftX currently supports 10
>microcontroller families (ARM. Coldfire, MSP430, AVR, 68HCS08, 68K,
>68HC12, 68HC11, 8051, i386, 69R000, and RTX2010.
And earlier you wrote:
|It typically takes a few weeks (2-4) to deal with a new processor plus
|drivers, etc., and including fairly serious performance goals.
So while that's not a huge job, it's not a small one, either. You
expect a certain level of demand before you take that job. Given the
time budget we have had for Gforth, we certainly could not afford that
for all the architectures that we tested on (and Gforth ran on
platforms that we had not tested on). For 0.7.0, we tested on Alpha,
ARM, IA-32, IA-64, PowerPC, PowerPC64, SPARC, AMD64 (8 architectures),
and it probably worked on other architectures (including HPPA and
MIPS, which we had tested for 0.6.2).
If we had restricted Gforth to be pure Forth-in-Forth, we would not
have achieved the goals we wanted to achieve. For those who want this
kind of purity for whatever reasons, there are a number of Forth
systems available, foremost among them colorForth.
- 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-16 09:42 -0700 |
| Message-ID | <7x38g9broz.fsf@ruckus.brouhaha.com> |
| In reply to | #30425 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > If we had restricted Gforth to be pure Forth-in-Forth, we would not > have achieved the goals we wanted to achieve. For those who want this > kind of purity for whatever reasons, there are a number of Forth > systems available, foremost among them colorForth. I've been wondering about the idea of a Forth-in-Forth compiling to a colorForth or retroForth-like virtual machine, which could in turn be a target for something like GNU Lightning or your proposed PAF. There could be a tiny low-level portable interpreter written in C for machines that didn't yet have Lightning/PAF targets.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-16 17:21 +0000 |
| Message-ID | <2014May16.192114@mips.complang.tuwien.ac.at> |
| In reply to | #30426 |
Paul Rubin <no.email@nospam.invalid> writes:
>I've been wondering about the idea of a Forth-in-Forth compiling to a
>colorForth or retroForth-like virtual machine, which could in turn be a
>target for something like GNU Lightning or your proposed PAF.
Come again? Do you mean a colorForth that targets GNU Lightning or
PAF, or vice versa?
Either way does not make much sense to me:
1) Machine Forth/ColorForth for the Pentium works nicely by expanding
the relatively low number of primitives directly into machine code.
Retargeting the architecture-specific part of that really should be
little work (less work for the architectures supported by GNU
Lightning than interfacing with GNU Lightning; and PAF is just a
concept yet). The main problem with colorForth is that it runs
directly on bare hardware, so it runs on only a few machines, or you
have to put virtualized hardware between colorForth and the real
machine.
2) The idea of PAF and GNU Lightning is to map to instructions on
register machines. Going through a stack-based VM that then expands
many VM instructions to several machine instructions is
counterproductive.
- 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-16 10:45 -0700 |
| Message-ID | <7xwqdl7h3m.fsf@ruckus.brouhaha.com> |
| In reply to | #30430 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > Come again? Do you mean a colorForth that targets GNU Lightning or > PAF, or vice versa? I just mean a virtual machine loosely inspired by colorForth, i.e. one that emulated a simple instruction set. > 1) Machine Forth/ColorForth for the Pentium works nicely by expanding > the relatively low number of primitives directly into machine code. I was thinking of the GA144 version, which has 5-bit opcodes directly executed by the hardware. A "loosely inspired" software interpreter would probably use 8-bit opcodes. > 2) The idea of PAF and GNU Lightning is to map to instructions on > register machines. Going through a stack-based VM that then expands > many VM instructions to several machine instructions is > counterproductive. It could be a register-based VM like Lua uses. For that matter, even the GA144 has a few registers (not enough for Lightning but it's easy to have more).
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-13 12:56 -0500 |
| Message-ID | <47qdnXip89VGwe_OnZ2dnUVZ_jadnZ2d@supernews.com> |
| In reply to | #30337 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>But this doesn't reduce the advantage of Forth-in-Forth, of course. >>> >>> For simple systems like eForth, yes. For complex ones like Gforth, >>> I have my doubts. E.g., the primitive generator prims2x.fs is >>> written in Forth , but I don't have the impression that this has >>> inspired anyone to tinker with it. The cross-compiler is also >>> written in Forth, and even I don't touch it (and avoid dealing with >>> it if I can). >> >>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. > in that case you are free to use any of the systems that value > simplicity over Gforth's goals, say colorForth. Indeed, but that's rather beside the point. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-14 12:03 +0000 |
| Message-ID | <2014May14.140323@mips.complang.tuwien.ac.at> |
| In reply to | #30340 |
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. Indeed,
I think that Gforth is the only one that uses a primitive generator,
and it probably will continue doing so when we switch to more direct
native code generation and become more Forth-in-Forthy.
Having a primitive generator was one of the consequences of Gforth's
efficiency goal. The idea was to implement relatively many words as
primitives (e.g., 2DUP as primitive rather than as ": 2dup over over
;") to gain performance. The primitive generator makes it easier and
less bug-prone to write primitives, because the tedious and
error-prone implementation of stack accesses is automated. Later it
made it possible to add static superinstructions and static stack
caching with little effort in the primitive specification file.
An analytic Forth compiler needs to know the stack effects of the
primitives, so we will reuse the primitive specifications for that, so
we still need the primitive generator for the native-code compiler,
even when that is written in Forth and generates machine code
directly.
So no, the primitive generator is in no way a consequence of using
some non-Forth tools when buildig a Forth system. Therefore its
existence does not support your theory.
>> in that case you are free to use any of the systems that value
>> simplicity over Gforth's goals, say colorForth.
>
>Indeed, but that's rather beside the point.
Maybe it is beside your point, but my point is: Simplicity is not the
only relevant criterion. If it was, all people would be using
colorForth or whatever the simplest system around is. Are you using
colorForth? If not, why not?
- 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-14 09:17 -0700 |
| Message-ID | <7xha4sl4hf.fsf@ruckus.brouhaha.com> |
| In reply to | #30368 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> e.g., 2DUP as primitive rather than as ": 2dup over over ;") to gain
> performance. ... An analytic Forth compiler needs to know the stack
> effects of the primitives, so we will reuse the primitive
> specifications for that, so we still need the primitive generator for
> the native-code compiler, even when that is written in Forth and
> generates machine code directly.
I'd hope a compiler with good locals support could handle writing all
the traditional primitives directly in Forth without any special tools
or generators:
: 2dup { x y } x y x y ;
: dup { x } x x ;
: swap { x y } y x ;
: drop { x } ;
et cetera. These would all be defined in a library that gets loaded
into user programs by default but could be overridden, like the Haskell
prelude.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-14 16:50 +0000 |
| Message-ID | <2014May14.185052@mips.complang.tuwien.ac.at> |
| In reply to | #30376 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> e.g., 2DUP as primitive rather than as ": 2dup over over ;") to gain
>> performance. ... An analytic Forth compiler needs to know the stack
>> effects of the primitives, so we will reuse the primitive
>> specifications for that, so we still need the primitive generator for
>> the native-code compiler, even when that is written in Forth and
>> generates machine code directly.
>
>I'd hope a compiler with good locals support could handle writing all
>the traditional primitives directly in Forth without any special tools
>or generators:
>
> : 2dup { x y } x y x y ;
> : dup { x } x x ;
> : swap { x y } y x ;
> : drop { x } ;
>
>et cetera.
Forth consists of more than stack manipulation words.
What you are thinking of would work in the kind of Forth compiler I
have in mind, but would not be very effective; it would cause quite a
lot of compiler overhead.
However, on a different level these definitions would work, and be
somewhat effective: For implementing compile, for these words; they
would work on the compile-time representation of the data stack. But
of course, it's even more effective to do
: 2dup 2dup ;
etc. instead.
Concerning the primitive generator: We already have >300 primitive
specifications for that, with correct (tested) stack effects. Ok, for
the native-code compiler we have to add code generation code for many
of them, but going away from the generator does not save us from 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 | AKK <akk@nospam.org> |
|---|---|
| Date | 2014-05-14 20:26 +0200 |
| Message-ID | <5373b53f$0$6607$9b4e6d93@newsspool4.arcor-online.net> |
| In reply to | #30376 |
Am 14.05.2014 18:17, schrieb Paul Rubin:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> e.g., 2DUP as primitive rather than as ": 2dup over over ;") to gain
>> performance. ... An analytic Forth compiler needs to know the stack
>> effects of the primitives, so we will reuse the primitive
>> specifications for that, so we still need the primitive generator for
>> the native-code compiler, even when that is written in Forth and
>> generates machine code directly.
>
> I'd hope a compiler with good locals support could handle writing all
> the traditional primitives directly in Forth without any special tools
> or generators:
>
> : 2dup { x y } x y x y ;
> : dup { x } x x ;
> : swap { x y } y x ;
> : drop { x } ;
>
> et cetera. These would all be defined in a library that gets loaded
> into user programs by default but could be overridden, like the Haskell
> prelude.
>
That's why I never adopted the current locals proposal:
: ROT { a b c -- b c a } ;
is equivalent to 3DROP.
Ugly. Unforthish IMO.
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2014-05-14 20:38 +0200 |
| Message-ID | <1kp1tt1kri9g0$.1ece2m93g6fn3$.dlg@40tude.net> |
| In reply to | #30382 |
Op Wed, 14 May 2014 20:26:20 +0200 schreef AKK:
<snip>
>
> That's why I never adopted the current locals proposal:
>: ROT { a b c -- b c a } ;
> is equivalent to 3DROP.
>
> Ugly. Unforthish IMO.
: ROT { a b c } ;
is 3DROP too.
: ROT { a b c } b c a ;
is ROT
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-05-14 20:02 -0400 |
| Message-ID | <op.xfvjq5f06zenlw@localhost> |
| In reply to | #30376 |
On Wed, 14 May 2014 12:17:16 -0400, Paul Rubin <no.email@nospam.invalid>
wrote:
> I'd hope a compiler with good locals support could handle writing all
> the traditional primitives directly in Forth without any special tools
> or generators:
>
> : 2dup { x y } x y x y ;
> : dup { x } x x ;
> : swap { x y } y x ;
> : drop { x } ;
>
> et cetera. These would all be defined in a library that gets loaded
> into user programs by default but could be overridden, like the Haskell
> prelude.
First, if locals are implemented on a separate stack, as a few others
here have said they've done for their Forth implementations, how would
those definitions even work? They would need to work against the data
or parameter stack, not the separate locals stack.
Second, why are special tools or generators needed to code the
traditional primitives directly in Forth?
Third, can't you do the same thing by defining some Forth variables?
VARIABLE A
VARIABLE B
: A@ A @ ;
: A! A ! ;
: B@ B @ ;
: B! B ! ;
: 2DUP A! B! B@ A@ B@ A@ ;
: DUP A! A@ A@ ;
: SWAP A! B! A@ B@ ;
: DROP A! ;
So, what is the real difference with locals? Is it where the local
is stored? e.g., on the stack instead of in memory. If that's the
case, a word LOCAL , functioning similar to VARIABLE , but which
allocates space on the stack, would be better. Wouldn't it?
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-15 14:22 +0000 |
| Message-ID | <2014May15.162231@mips.complang.tuwien.ac.at> |
| In reply to | #30388 |
"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>On Wed, 14 May 2014 12:17:16 -0400, Paul Rubin <no.email@nospam.invalid>
>wrote:
>
>> I'd hope a compiler with good locals support could handle writing all
>> the traditional primitives directly in Forth without any special tools
>> or generators:
>>
>> : 2dup { x y } x y x y ;
>> : dup { x } x x ;
>> : swap { x y } y x ;
>> : drop { x } ;
>>
>> et cetera. These would all be defined in a library that gets loaded
>> into user programs by default but could be overridden, like the Haskell
>> prelude.
>
>First, if locals are implemented on a separate stack, as a few others
>here have said they've done for their Forth implementations, how would
>those definitions even work? They would need to work against the data
>or parameter stack, not the separate locals stack.
Locals definitions take their initial value from the data stack, and
locals uses push the vaue of the local on the data stack. That's
independent of whether the locals are stored in registers, on the
return stack or on a dedicated locals stack.
BTW, the code above assumes that locals are stored in registers, and
that the compiler is smart enough to avoid generating lots of
register-register moves.
>Second, why are special tools or generators needed to code the
>traditional primitives directly in Forth?
They are not, as various Forth systems that work without such a
generator demonstrate.
>Third, can't you do the same thing by defining some Forth variables?
>
>VARIABLE A
>VARIABLE B
>
>: A@ A @ ;
>: A! A ! ;
>: B@ B @ ;
>: B! B ! ;
>
>: 2DUP A! B! B@ A@ B@ A@ ;
>: DUP A! A@ A@ ;
>: SWAP A! B! A@ B@ ;
>: DROP A! ;
>
>So, what is the real difference with locals? Is it where the local
>is stored? e.g., on the stack instead of in memory.
For the stuff that Paul Rubin was probably thinking of, yes, that
would make the difference, at least with the kind of compiler I have
in mind. The locals version SWAP would ideally result in 0 or a few
register-register moves, whereas the memory version would result in
two stores and two loads.
> If that's the
>case, a word LOCAL , functioning similar to VARIABLE , but which
>allocates space on the stack, would be better. Wouldn't it?
Better than what? For what purpose?
- 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-15 17:39 -0400 |
| Message-ID | <op.xfw7seuw6zenlw@localhost> |
| In reply to | #30400 |
On Thu, 15 May 2014 10:22:31 -0400, Anton Ertl
<anton@mips.complang.tuwien.ac.at> wrote:
> "Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>> If that's the case, a word LOCAL , functioning similar to VARIABLE ,
>> but which allocates space on the stack, would be better. Wouldn't it?
>
> Better than what? For what purpose?
>
Well, I started to say better syntax: LOCAL x LOCAL y defined
globally like VARIABLE x VARIABLE y. At first, I didn't see the
point of needing braces { } to delimit defining 'x' and 'y'. Now,
I'm guessing that 'x' and 'y' aren't global, but 'x' and 'y' have
local scope limited to the defining Forth word.
So, 'x' and 'y' in 2DUP are different from those in DUP SWAP DROP
and also different for each instance of 2DUP. Therefore, these
Forth locals are just like the named function parameters used in C.
In which case, locals are providing a name for parameters to Forth
words, but are being named after the fact. Now that the Forth
parameters are named, an optimizer can relocate them wherever it
wants: stack, memory, or register. Since they're temporary, they
can be allocated and free'd the same was as C does in it's procedure
calling conventions.
If that understanding is correct, that's an interesting way to
introduce optimizations which C has, such as registers, into Forth.
It would also mean that the braces { } delimit the parameter list.
I'm assuming that older, non-optimizing Forths will just define a
temporary variable with the address location for the item on the
stack. But, I'm not sure how older Forths would handle destroying
or freeing the variable at the end-of-use, without major internal
changes to the interpreter. Where is the garbage collection in an
interpreted Forth? ...
I can also see the braces syntax being a slight implementation issue
for older Forths too. The { brace would need to be some type of
looping word to fetch the name of each local to be defined. That
could be a problem too. E.g., in my interpreted Forth, looping words
are not available until almost all other words have been defined.
I.e., the need for looping could restrict implementation and usage
of locals until most of the dictionary was complete, as in my case.
That partially defeats the purpose of locals.
So, it still might be better to use a single Forth word instead of
delimiters to indicate locals. Then, a definition which works on
simple Forths might be more forthcoming. Perhaps, LOCAL within the
colon definition could be used:
: 2DUP ( x y -- x y x y ) LOCAL x LOCAL y x y x y ;
The standard stack comment placed between the end of the locals
and the definition body could be used prevent confusion.
: 2DUP LOCAL x LOCAL y ( x y -- x y x y ) x y x y ;
Or, some other comment:
: 2DUP ( x y -- x y x y ) LOCAL x LOCAL y ( body ) x y x y ;
I'd say that if locals of any form are widely adopted, it should
definately improve optimizing Forths and help with conversion of
Forth to C. But, I'm uncertain as to how difficult or easy it
would be to implement this within an interpreted Forth. Currently,
I think it would have some issues as mentioned above (looping,
garbage collection). I.e., this seems to be a feature that
preferences modern Forths.
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web