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 | 15 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 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-05-20 21:28 +0200 |
| Message-ID | <llgact$b0a$1@online.de> |
| In reply to | #30474 |
Anton Ertl wrote: >>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. No. The additional cell would come first, before any other stuff. The header format doesn't change otherwise, it is just an extension (towards negative addresses). The fact that it will be a bit complicated to get at that cell is unimportant, because it is only there for VIEW. The rest of the header will stay as is, and not require any change at all. : >view ( xt -- view-addr ) name>string drop cell negate and cell- ; The view field itself needs three numbers inside: file number, line number and column number. On 32 bits, I would choose 8/16/8 bit for those, on 64 bits 16/32/16 (that should be enough for anybody ;-). > 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. I suppose the most complex part is to make sure that all primitives get their original location in prim, because otherwise, you would only view the alias in aliases.fs. That part requites a change to prims2x.fs, as well. A trivial change, as we do similar stuff to the C sources. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-05-20 21:56 +0100 |
| Message-ID | <llgfia$lg6$1@dont-email.me> |
| In reply to | #30491 |
on 20/05/2014 20:28:27, Bernd Paysan wrote:
> The view field itself needs three numbers inside: file number, line
> number and column number. On 32 bits, I would choose 8/16/8 bit for
> those, on 64 bits 16/32/16 (that should be enough for anybody ;-).
You might be able to ditch the file number; I have.
As files are included, the xts they define get built at ascending
addresses at HERE. Each filename is a word in a special files vocabulary;
when executed, it returns an address pair, the min and max address range
for this file. The filename word is built by INCLUDE.
To get the filename for a specific xt, the files vocabulary is iterated
and the names are executed to get the range. For example, for a file A
which includes B and C, the xt min and max address range shown as [ ]
might be
[-------------------------- console ------------------]
[----------------- file A -----------------------]
[----- file B -----] [- file C -]
X Y Z
X is defined in A; Y is defined in B. Z is defined from the console.
TRAVERSE-WORDLIST and EXECUTE the files to get their range information,
looking for the smallest span (max - min) that contains the xt. Y is in
both A and B, but B's span is smaller. The console range is a dummy that
covers all of the addressable memory.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-05-21 00:21 +0200 |
| Message-ID | <llgkh7$qrg$2@online.de> |
| In reply to | #30496 |
Alex McDonald wrote: > on 20/05/2014 20:28:27, Bernd Paysan wrote: >> The view field itself needs three numbers inside: file number, line >> number and column number. On 32 bits, I would choose 8/16/8 bit for >> those, on 64 bits 16/32/16 (that should be enough for anybody ;-). > > You might be able to ditch the file number; I have. I have enough space for the file number, so I will go for "keep it simple". -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-05-21 21:42 +0000 |
| Message-ID | <537d1dd8$0$27166$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #30502 |
In article <llgkh7$qrg$2@online.de>, Bernd Paysan <bernd.paysan@gmx.de> wrote: >Alex McDonald wrote: > >> on 20/05/2014 20:28:27, Bernd Paysan wrote: >>> The view field itself needs three numbers inside: file number, line >>> number and column number. On 32 bits, I would choose 8/16/8 bit for >>> those, on 64 bits 16/32/16 (that should be enough for anybody ;-). >> >> You might be able to ditch the file number; I have. > >I have enough space for the file number, so I will go for "keep it simple". Yet simpler. There is enough space for the files. So LOCATE can use a simple pointer to the file buffer. Something like SRC @ IN @ + , added to the header. This doesn't work for system words, of course. > >-- >Bernd Paysan > 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-05-22 02:15 +0200 |
| Message-ID | <lljfjr$llb$1@online.de> |
| In reply to | #30541 |
Albert van der Horst wrote: > Yet simpler. > There is enough space for the files. So LOCATE can use a simple pointer to > the file buffer. > Something like SRC @ IN @ + , added to the header. > > This doesn't work for system words, of course. We save all the file names we load in an array, so the index into this array is something straight-forward, without changing anything else in Gforth. -- 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-23 14:47 +0000 |
| Message-ID | <2014May23.164743@mips.complang.tuwien.ac.at> |
| In reply to | #30541 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>Yet simpler.
>There is enough space for the files. So LOCATE can use a simple pointer to
>the file buffer.
>Something like SRC @ IN @ + , added to the header.
>
>This doesn't work for system words, of course.
Sure, we could mmap the source files for the system words, too. It's
cute, but VIEW would be more complicated.
- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-21 14:12 +0000 |
| Message-ID | <2014May21.161241@mips.complang.tuwien.ac.at> |
| In reply to | #30491 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>>>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.
>
>No. The additional cell would come first, before any other stuff. The
>header format doesn't change otherwise, it is just an extension (towards
>negative addresses).
Ok, so in this case we have a compatible change, and issue 2) does not
apply.
>The view field itself needs three numbers inside: file number, line number
>and column number. On 32 bits, I would choose 8/16/8 bit for those, on 64
>bits 16/32/16 (that should be enough for anybody ;-).
We alread have started with something like that (IIRC for this
purpose), and we have it in source.fs. For LOCATE we also need the
length, unless we determine what to show by looking for empty lines.
The column is useful for ~~ and ASSERT(, not so much for VIEW and
LOCATE.
>I suppose the most complex part is to make sure that all primitives get
>their original location in prim, because otherwise, you would only view the
>alias in aliases.fs. That part requites a change to prims2x.fs, as well. A
>trivial change, as we do similar stuff to the C sources.
Yes. There is even a #LINE in source.fs. Does not look complex to
me.
- 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 | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-05-21 21:24 +0000 |
| Message-ID | <537d199e$0$27166$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #30474 |
In article <2014May20.143604@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
<SNIP>
>>
>>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.
Well. In ciforth there is a foresight that you may want to have
an extra field to play with. In general if you want a simple modification
of a version you've only to modify a configuration file.
There is an option in ciforth that you can choose in a e.g.
lina64.cfg by adding this line:
define({_EXTRAFIELD_},_yes)dnl
The realization of this feature is equally simple
In header.m4 is present in the HEADER macro an extra line:
_EXTRAFIELD_({ DC 0 })
And the postlude.m4 takes care that the headersize stays correct:
_EXTRAFIELD_(define({M4_HS},M4_HS+1)})
If you'd do this by hand you would:
1. add `` DC 0 '' at the appropriate place
2. Replace `` define({M4_HS},{5}) '' by `` define({M4_HS},{6}) ''
This is the kind of effort that should be sufficient for such a
simple change.
>
>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.
I wouldn't say it's cute. It is a test whether a setup is sufficiently
robust to handle changes in requirements.
>
>- anton
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 | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-05-10 12:00 +0000 |
| Message-ID | <536e14fa$0$27170$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #30244 |
In article <dYSdncZm_NehYvDOnZ2dnUVZ_rydnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > >This needs a fuller explanation. If you write Forth in not-Forth, and >paricularly if you write it in a compiled language like C, then unless >you are a C compiler expert there is a substantial (and critical!) >part of the implementation that you don't control. You depend on the >implementation of that langauge. This isn't just a Forth thing: >lisp-in-lisp has the same properties. I don't usually do follow ups like this, but ... This is an extremely important point. > >Andrew. -- 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-05-10 13:16 -0400 |
| Message-ID | <lklmv3$t65$1@dont-email.me> |
| In reply to | #30244 |
On 5/10/2014 6:28 AM, Andrew Haley wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >> rickman <gnuarm@gmail.com> wrote: >>> On 5/9/2014 5:14 AM, Andrew Haley wrote: >>>> rickman <gnuarm@gmail.com> wrote: >>>>> On 5/7/2014 4:31 PM, Paul Rubin wrote: >>>>>> Laurent Laborde <kerdezixe@gmail.com> writes: >>>>>>> I just read that "gforth is too bloated". >>>>>>> That's an honest question : what do you mean by "too bloated" ? >>>>> ...snip... >>>>>> I like it as a user, but since a lot of it is written in C, it misses >>>>>> (it seems to me) some of the technical elegance of a pure metacompiled >>>>>> Forth written in Forth. >>>>> >>>>> Who cares what it is written in? How does that impact your experience >>>>> as a user? >>>> >>>> Because Forth is mutable; the user can change it without needing the >>>> help of a high priest. The user is encouraged to understand how it >>>> works, because knowledge is power. >>> >>> So you can't read C code? >> >> Yes, but that's not the point: it's about control, and about >> freedom. > > This needs a fuller explanation. If you write Forth in not-Forth, and > paricularly if you write it in a compiled language like C, then unless > you are a C compiler expert there is a substantial (and critical!) > part of the implementation that you don't control. You depend on the > implementation of that langauge. This isn't just a Forth thing: > lisp-in-lisp has the same properties. > > Andrew. If you follow your line of reasoning, in order to have the same level of control of a Forth written in Forth, you need to be a Forth compiler expert. That is nothing like being a Forth user. As to the freedom part, that seems to be a bit overstated. You have all the same freedom no matter what language it is written in. Here again are the parts I was responding to... >>>>>> I like it as a user, but since a lot of it is written in C, it misses >>>>>> (it seems to me) some of the technical elegance of a pure metacompiled >>>>>> Forth written in Forth. ...and... >>>> Because Forth is mutable; the user can change it without needing the >>>> help of a high priest. The user is encouraged to understand how it >>>> works, because knowledge is power. From your statements, it is only clear that for a Forth written in Forth the user needs to be a Forth high priest rather than a C high priest. I don't see any significant advantage in that. I think we are splitting some fine hairs here. The initial statement was about "elegance" which has no meaning to me. Elegance is nice (if you can even define that) but it means nothing to me when I am writing code. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-10 11:05 -0700 |
| Message-ID | <7xtx8xwluf.fsf@ruckus.brouhaha.com> |
| In reply to | #30265 |
rickman <gnuarm@gmail.com> writes: > If you follow your line of reasoning, in order to have the same level > of control of a Forth written in Forth, you need to be a Forth > compiler expert. That is nothing like being a Forth user. I'm not a Forth high priest or even much of a user. I read the eForth implementation and found it understandable. I think it's mostly a matter of the amount of code involved. Historical Forths tended to be very simple compared to their C counterparts that relied on a lot of separate tools. Therefore, Forth users had more de facto ability than C users to change the implementation of the underlying language. Andrew has made versions of the above point on several occasions.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-10 18:11 -0500 |
| Message-ID | <caWdnXzHrIGPL_POnZ2dnUVZ_vidnZ2d@supernews.com> |
| In reply to | #30265 |
rickman <gnuarm@gmail.com> wrote: > On 5/10/2014 6:28 AM, Andrew Haley wrote: >> Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >>> rickman <gnuarm@gmail.com> wrote: >>>> On 5/9/2014 5:14 AM, Andrew Haley wrote: >>>>> rickman <gnuarm@gmail.com> wrote: >>>>>> On 5/7/2014 4:31 PM, Paul Rubin wrote: >>>>>>> Laurent Laborde <kerdezixe@gmail.com> writes: >>>>>>>> I just read that "gforth is too bloated". >>>>>>>> That's an honest question : what do you mean by "too bloated" ? >>>>>> ...snip... >>>>>>> I like it as a user, but since a lot of it is written in C, it misses >>>>>>> (it seems to me) some of the technical elegance of a pure metacompiled >>>>>>> Forth written in Forth. >>>>>> >>>>>> Who cares what it is written in? How does that impact your experience >>>>>> as a user? >>>>> >>>>> Because Forth is mutable; the user can change it without needing the >>>>> help of a high priest. The user is encouraged to understand how it >>>>> works, because knowledge is power. >>>> >>>> So you can't read C code? >>> >>> Yes, but that's not the point: it's about control, and about >>> freedom. >> >> This needs a fuller explanation. If you write Forth in not-Forth, and >> paricularly if you write it in a compiled language like C, then unless >> you are a C compiler expert there is a substantial (and critical!) >> part of the implementation that you don't control. You depend on the >> implementation of that langauge. This isn't just a Forth thing: >> lisp-in-lisp has the same properties. > > If you follow your line of reasoning, in order to have the same > level of control of a Forth written in Forth, you need to be a Forth > compiler expert. The classic Forth compiler is a few lines of code. How long does it take to become an expert in that? Okay, a metacompiler is harder and an optimizing compiler harder still, but we're still talking about something well within the reach of a reasonably skilled Forth programmer. > That is nothing like being a Forth user. I disagree. Forth systems are usually much simpler than conventional languages and operating systems -- that's the big idea -- so a Forth user can reasonably expect to get enough expertise to change the system to suit an application. > As to the freedom part, that seems to be a bit overstated. You have all > the same freedom no matter what language it is written in. Well, if you don't understand how something works you don't have mastery over it. > Here again are the parts I was responding to... > > >>>>>> I like it as a user, but since a lot of it is written in C, > >>>>>> it misses (it seems to me) some of the technical elegance of > >>>>>> a pure metacompiled Forth written in Forth. (not me) > > ...and... > > >>>> Because Forth is mutable; the user can change it without > >>>> needing the help of a high priest. The user is encouraged to > >>>> understand how it works, because knowledge is power. (me) > > From your statements, it is only clear that for a Forth written in > Forth the user needs to be a Forth high priest rather than a C high > priest. Not really, no: my point is that there don't need to be any high priests! A Forth programmer can understand the entire system. It's not that difficult. > The initial statement was about "elegance" which has no meaning to me. > Elegance is nice (if you can even define that) but it means nothing to > me when I am writing code. Oh dear. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-05-11 02:12 +0200 |
| Message-ID | <lkmf8t$61s$1@online.de> |
| In reply to | #30278 |
Andrew Haley wrote: >> The initial statement was about "elegance" which has no meaning to me. >> Elegance is nice (if you can even define that) but it means nothing to >> me when I am writing code. > > Oh dear. That's the culmination of him not being a master... If he wants a definition what "elegance" means in terms of programming: It is an intuitive (gut feeleing) grasp of the quality of a program. "Quality" has objective measures, like "how fast is it", "how many bugs are there", "how easy it is to maintain and understand", "how long did it take to write" and such, and of course this intuitive feeling corresponds to the objective qualities. It is intuitive, because if you master programming, you need to have a quick feedback that tells you whether you are writing bad or good code. This is not about wizard or high priest level, this is about craftsmanship level. Every craftsman has this gut feeling about his work (or at least should have it). -- 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-09 16:36 +0000 |
| Message-ID | <2014May9.183625@mips.complang.tuwien.ac.at> |
| In reply to | #30166 |
Paul Rubin <no.email@nospam.invalid> writes:
>I like it as a user, but since a lot of it is written in C
Hmm, let's see:
I do a fresh checkout from git and (after deleting the .git directory)
count the lines;
find . |grep '[.][ch]$'|xargs wc -l
counts a total of 40394 C lines (in 174 files). However, this
includes stuff like libltdl, vmgen examples, and support files for
Lego NXT and Beagleboard that are not included in most builds. The
main files used are in the engine directory, but there are also some
replacement files there, too (e.g., replacements for rint, pow10,
select, etc.). Let's look at how much is included in the engine
"gforth" on AMD64:
Thanks to the relatime misfeature I don't know for sure which files
were accessed during compilation, but a guess at the .c files (based
on the .o files) is:
476 engine/engine.c
2681 engine/main.c
771 engine/io.c
485 engine/signals.c
867 engine/support.c
28 engine/libmain.c
5308 total
Plus various .h files.
Let's see how much Forth code there is: 76507 lines in 365 files. Not
all of that is included in a build, either. For simplicity I assume
that everything in the kernel directory is actually in the kernel.
For the rest of the image .INCLUDED produces the file names. So I
use:
echo `gforth -e ".included bye"` kernel/*.fs|xargs wc -l
and get 16888 lines in about 89 files. I guess one might consider
that bloated.
There are also 108894 lines in 557 files (+directories) that are
neither C nor Forth (at least as far as the extensions are concerned),
among them 16859 lines in doc/gforth.ds (the manual) and 9125 in the
ChangeLog, and, more relevant for the implementation, 3185 lines in
prim (which is the source code for the primitives and is written in
vmgen).
- 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 | jacko <jackokring@gmail.com> |
|---|---|
| Date | 2014-05-07 20:01 -0700 |
| Message-ID | <56f5d5e9-c9b0-4b4e-a4bb-7c9a222b654b@googlegroups.com> |
| In reply to | #30165 |
bloated for what purpose it is put?
[toc] | [prev] | [standalone]
Page 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
Back to top | Article view | comp.lang.forth
csiph-web