Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #55085 > unrolled thread
| Started by | jim <njbetts@gmail.com> |
|---|---|
| First post | 2017-02-24 15:05 -0800 |
| Last post | 2017-02-27 01:21 -0500 |
| Articles | 20 on this page of 189 — 21 participants |
Back to article view | Back to comp.lang.forth
The Wikipedia article on Forth jim <njbetts@gmail.com> - 2017-02-24 15:05 -0800
The Wikipedia article on Forth Mark Wills <markwills1970@gmail.com> - 2017-02-24 15:14 -0800
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-02-24 23:38 -0800
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-02-25 04:51 -0600
Re: The Wikipedia article on Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-25 13:00 +0100
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-02-26 14:29 +1100
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-02-26 09:30 +0000
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-26 02:44 -0800
Re: The Wikipedia article on Forth Julian Fondren <julian.fondren@gmail.com> - 2017-02-26 03:12 -0800
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-26 03:25 -0800
Re: The Wikipedia article on Forth Paul Rubin <no.email@nospam.invalid> - 2017-02-26 14:00 -0800
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-26 14:32 -0800
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-02-26 22:58 +0000
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-26 15:29 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-02-26 21:57 -0500
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-02-26 19:17 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-02-26 22:21 -0500
Re: The Wikipedia article on Forth Paul Rubin <no.email@nospam.invalid> - 2017-02-26 15:41 -0800
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-02-26 14:46 -1000
Re: The Wikipedia article on Forth Paul Rubin <no.email@nospam.invalid> - 2017-02-26 17:08 -0800
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-02-26 15:18 -1000
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-27 14:20 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-02-27 17:47 -0500
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-27 15:16 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-02-27 19:04 -0500
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-27 21:52 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-02-28 01:12 -0500
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-28 03:33 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-02-28 19:23 -0500
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-01 08:04 -0800
Re: The Wikipedia article on Forth Cecil Bayona <cbayona@cbayona.com> - 2017-02-27 18:54 -0600
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-28 03:17 -0800
Re: The Wikipedia article on Forth Paul Rubin <no.email@nospam.invalid> - 2017-02-28 03:50 -0800
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-28 05:28 -0800
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-02-28 13:59 -0800
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-01 08:25 -0800
Re: The Wikipedia article on Forth Paul Rubin <no.email@nospam.invalid> - 2017-02-27 23:00 -0800
Re: The Wikipedia article on Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-28 11:51 +0100
Re: The Wikipedia article on Forth Mark Wills <markwills1970@gmail.com> - 2017-02-28 05:19 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-02-28 19:34 -0500
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-28 03:42 -0800
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-10 10:16 +1100
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-09 18:21 -0500
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-09 23:44 +0000
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-09 19:55 -0500
Re: The Wikipedia article on Forth Paul Rubin <no.email@nospam.invalid> - 2017-03-10 11:24 -0800
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-03-10 13:38 -0800
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-11 12:08 +0000
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-03-09 16:34 -1000
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-03-09 22:43 -0800
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-11 15:23 +1100
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-10 21:17 +1100
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-11 12:06 +0000
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-12 05:32 -0500
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-12 11:17 +0000
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-12 13:18 +0000
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-12 14:59 +0000
Re: The Wikipedia article on Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-03-12 15:00 -0400
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-13 10:43 +1100
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-13 07:57 +0000
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-13 10:26 +0000
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-10 03:27 -0600
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-03-10 08:47 -1000
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-11 01:57 -0600
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-02-26 10:00 -0800
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-02-26 18:32 +0000
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-02-26 11:52 -0800
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-02-26 20:23 +0000
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-26 11:21 -0800
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-02-26 19:41 +0000
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-26 11:55 -0800
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-02-26 20:14 +0000
Re: The Wikipedia article on Forth Julian Fondren <julian.fondren@gmail.com> - 2017-02-26 12:37 -0800
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-26 14:26 -0800
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-02-27 14:10 +1100
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-02-26 19:43 -0800
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-02-27 04:13 -0600
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-27 14:31 -0800
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-02-28 03:53 -0600
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-02-27 13:15 +1100
Re: The Wikipedia article on Forth Mark Wills <markwills1970@gmail.com> - 2017-02-27 02:22 -0800
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-02-27 15:52 -1000
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-02-28 14:44 +1100
Re: The Wikipedia article on Forth Paul Rubin <no.email@nospam.invalid> - 2017-02-27 22:55 -0800
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-04 21:38 +1100
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-04 06:11 -0500
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-04 12:21 +0000
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-04 13:27 -0500
Re: The Wikipedia article on Forth JUERGEN <epldfpga@aol.com> - 2017-03-05 08:50 -0800
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-08 15:12 +0000
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-05 18:25 +1100
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-05 02:38 -0500
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-07 18:20 +1100
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-07 02:45 -0500
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-07 08:54 +0000
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-07 04:42 -0500
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-07 04:06 -0600
Re: The Wikipedia article on Forth Roelf Toxopeus <rt4all@nothishetnet.nl> - 2017-03-07 13:02 +0100
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-08 18:43 +1100
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-03-07 22:04 -1000
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-08 19:49 +1100
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-08 19:02 -0500
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-08 10:06 +0000
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-08 03:35 -0500
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-08 13:41 +0000
Re: The Wikipedia article on Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-08 15:29 +0100
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-08 15:10 +0000
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-07 08:31 +0000
Re: The Wikipedia article on Forth Bernd Paysan <bernd@net2o.de> - 2017-03-11 22:03 +0000
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-11 22:56 +0000
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-12 05:36 -0500
Re: The Wikipedia article on Forth stephen@mpeforth.com (Stephen Pelc) - 2017-03-12 15:14 +0000
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-03-12 19:46 -0700
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-04 12:09 +0000
Re: The Wikipedia article on Forth alex@rivadpm.com - 2017-03-05 15:28 -0800
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-05 22:05 +0000
Re: The Wikipedia article on Forth julian.fondren@endurance.com - 2017-03-04 07:23 -0800
Re: The Wikipedia article on Forth Bernd Paysan <bernd@net2o.de> - 2017-03-11 22:11 +0000
Re: The Wikipedia article on Forth Julian Fondren <julian.fondren@gmail.com> - 2017-03-04 07:25 -0800
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-05 19:10 +1100
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-05 04:27 -0500
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-03-05 18:24 -0800
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-07 18:16 +1100
Re: The Wikipedia article on Forth stephen@mpeforth.com (Stephen Pelc) - 2017-03-07 11:35 +0000
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-03-07 17:13 -1000
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-08 19:10 +1100
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-08 03:38 -0500
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-08 10:18 +0000
Re: The Wikipedia article on Forth Bernd Paysan <bernd@net2o.de> - 2017-03-11 22:41 +0000
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-03-11 16:50 -1000
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-12 09:56 +0000
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-03-12 14:31 -1000
Re: The Wikipedia article on Forth Bernd Paysan <bernd@net2o.de> - 2017-03-15 23:54 +0000
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-03-15 19:00 -0700
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-03-15 21:27 -0700
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-03-15 21:39 -0700
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-03-15 22:13 -0700
Re: The Wikipedia article on Forth stephen@mpeforth.com (Stephen Pelc) - 2017-03-16 10:20 +0000
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-03-12 19:42 -0700
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-03-12 19:39 -0700
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-12 05:48 -0500
Re: The Wikipedia article on Forth Mark Wills <markwills1970@gmail.com> - 2017-03-06 01:26 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-06 05:33 -0500
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-06 04:33 -0600
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-06 17:16 +0000
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-06 12:28 -0600
Re: The Wikipedia article on Forth Mark Wills <markwills1970@gmail.com> - 2017-03-06 11:10 -0800
Re: The Wikipedia article on Forth Mark Wills <markwills1970@gmail.com> - 2017-03-06 11:12 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-06 15:22 -0500
Re: The Wikipedia article on Forth Julian Fondren <julian.fondren@gmail.com> - 2017-03-06 12:28 -0800
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-07 02:51 -0600
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-07 13:13 +0000
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-07 14:50 -0500
Re: The Wikipedia article on Forth Julian Fondren <julian.fondren@gmail.com> - 2017-03-07 12:06 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-07 16:00 -0500
Re: The Wikipedia article on Forth julian.fondren@endurance.com - 2017-03-07 13:18 -0800
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-08 00:16 +0000
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-08 03:04 -0600
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-08 09:52 +0000
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-08 05:09 -0600
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-08 14:05 +0000
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-08 12:05 -0600
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-08 03:00 -0600
Re: The Wikipedia article on Forth Bernd Paysan <bernd@net2o.de> - 2017-03-11 22:53 +0000
Re: The Wikipedia article on Forth Bernd Paysan <bernd@net2o.de> - 2017-03-11 23:19 +0000
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-03-11 17:01 -1000
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-12 10:12 +0000
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-12 07:02 -0500
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-12 12:43 +0000
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-12 12:28 -0500
Re: The Wikipedia article on Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-12 16:29 +0100
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-12 16:16 +0000
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-12 21:42 +0000
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-08 19:13 +1100
Re: The Wikipedia article on Forth Mark Wills <markwills1970@gmail.com> - 2017-03-08 01:33 -0800
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-10 10:37 +1100
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-03-04 18:35 -0800
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-02-27 23:12 -0800
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-02-27 13:13 +0000
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-02-27 23:28 -0800
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-02-28 07:49 +0000
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-02-28 03:32 -0500
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-02-25 11:55 +1100
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-02-24 22:14 -1000
Re: The Wikipedia article on Forth Roelf Toxopeus <rt4all@nothishetnet.nl> - 2017-02-26 15:15 +0100
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-02-26 20:02 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-02-26 23:08 -0500
Re: The Wikipedia article on Forth Cecil Bayona <cbayona@cbayona.com> - 2017-02-26 23:27 -0600
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-02-27 01:21 -0500
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-03-08 14:05 +0000 |
| Message-ID | <2017Mar8.150504@mips.complang.tuwien.ac.at> |
| In reply to | #55538 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>
>> Did not know about [ByteBuffers]. They certainly look interesting,
>> especially because they have methods for accessing the memory as
>> chars, ints, longs, etc. But I think that an int[] performs better
>> on Intel and ARM than a ByteBuffer with default order()
>> (BIG_ENDIAN), and even on SPARC (which is big-endian, but did not
>> support efficient unaligned accesses last I looked).
>
>I did a lot of work on ByteBuffers to make them fast. It all depends
>on how exactly they are used by a Java application, but in many (most,
>I hope) cases there shouldn't be a significant slowdown over using an
>int[]. This will be in JDK 9, but anbody working in an area where a
>ByteBuffer might be useful should anticipate JDK 9.
I looked at one implementation of ByteBuffer (IIRC in JDK 7), and it
called various methods from the class Bits, and the implementation
there looked looked very much like
<http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/nio/Bits.java>;
e.g.,
private static byte [More ...] int3(int x) { return (byte)(x >> 24); }
...
static void [More ...] putIntL(ByteBuffer bb, int bi, int x) {
bb._put(bi + 3, int3(x));
bb._put(bi + 2, int2(x));
bb._put(bi + 1, int1(x));
bb._put(bi + 0, int0(x));
}
static void [More ...] putInt(ByteBuffer bb, int bi, int x, boolean bigEndian) {
if (bigEndian)
putIntB(bb, bi, x);
else
putIntL(bb, bi, x);
}
Did you replace this with something more efficient, or is it still the
same, with added smarts in the JIT to make this code fast?
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-08 12:05 -0600 |
| Message-ID | <WoOdnbGBJe5q2l3FnZ2dnUU7-N3NnZ2d@supernews.com> |
| In reply to | #55546 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>
>>> Did not know about [ByteBuffers]. They certainly look interesting,
>>> especially because they have methods for accessing the memory as
>>> chars, ints, longs, etc. But I think that an int[] performs better
>>> on Intel and ARM than a ByteBuffer with default order()
>>> (BIG_ENDIAN), and even on SPARC (which is big-endian, but did not
>>> support efficient unaligned accesses last I looked).
>>
>>I did a lot of work on ByteBuffers to make them fast. It all depends
>>on how exactly they are used by a Java application, but in many (most,
>>I hope) cases there shouldn't be a significant slowdown over using an
>>int[]. This will be in JDK 9, but anbody working in an area where a
>>ByteBuffer might be useful should anticipate JDK 9.
>
> I looked at one implementation of ByteBuffer (IIRC in JDK 7), and it
> called various methods from the class Bits, and the implementation
> there looked looked very much like
> <http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/nio/Bits.java>;
> e.g.,
>
> private static byte [More ...] int3(int x) { return (byte)(x >> 24); }
> ...
> static void [More ...] putIntL(ByteBuffer bb, int bi, int x) {
> bb._put(bi + 3, int3(x));
> bb._put(bi + 2, int2(x));
> bb._put(bi + 1, int1(x));
> bb._put(bi + 0, int0(x));
> }
> static void [More ...] putInt(ByteBuffer bb, int bi, int x, boolean bigEndian) {
> if (bigEndian)
> putIntB(bb, bi, x);
> else
> putIntL(bb, bi, x);
> }
>
> Did you replace this with something more efficient, or is it still the
> same, with added smarts in the JIT to make this code fast?
It's quite different. All of the accesses to Bits.{put,get}X are
gone, replaced with calls to Unsafe.{put,get}XUnaligned, and those
methods methods are JIT intrinsics. There have to be some checks for
things like bounds overflow, of course. But there are limits to this
ideal scenario: any optimizer has a visibility horizon and will
sometimes fail to generate optimal code. Like anything else involving
a JIT, some paths through the code will occasionally fail to work well
because the wrong inlining happened. All of this only works really
well if the checks for endianness/alignment/overflow can be hoisted
out of loops, which they usually can for idiomatic Java code. I don't
know if a Java Forth would generate sufficiently JIT-friendly code,
but I think it could be done.
One thing I found interesting was that it was actually more efficient
to handle the strict-alignment machines in Java code rather than
specially in the JIT. This is because hotspot, like many JITs,
gathers statistics data about branch execution frequency, and doesn't
generate code for things that have never happened. So, the only extra
code that gets generated on such machines is an unaligned check,
followed by a branch to a deoptimization trap.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-08 03:00 -0600 |
| Message-ID | <dfydnTH1SMOjVSLFnZ2dnUU7-TOdnZ2d@supernews.com> |
| In reply to | #55514 |
Julian Fondren <julian.fondren@gmail.com> wrote: > > By 'the JVM', Anton means the Java Virtual Machine. This is a VM > invented for the Java programming language, which has constant > bit-widths and such that don't vary by implementing or host > architecture. You can learn more about it at > https://infogalactic.com/info/Java_(programming_language) > > It's actually a fairly popular language! You'll be surprised by how > many know of it. And the JVM is a stack machine! > > By the story, the author of that Forth chose to use a char[] (16-bit) > instead of a byte[] (8-bit) array for Forth's memory. I've made that > mistake myself, of forgetting that a 'char' was a 16-bit type. For what it's worth: IMO the right way to handle memory on the JVM isn't a byte array, but a ByteBuffer. There are several advantages to this, in particular that you can read and write objects larger than bytes and map the buffer onto a file for persistency. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2017-03-11 22:53 +0000 |
| Message-ID | <oa1v4h$u80$6@dont-email.me> |
| In reply to | #55514 |
Am Tue, 07 Mar 2017 12:06:43 -0800 schrieb Julian Fondren: > By the story, the author of that Forth chose to use a char[] (16-bit) > instead of a byte[] (8-bit) array for Forth's memory. I've made that > mistake myself, of forgetting that a 'char' was a 16-bit type. Oh, that would have been fine, and 1 CHARS == 1. No, he used a byte[] array for Forth's memory, and chars take up two consecutive bytes in that memory. If you use a byte[] array, just encode the characters with UTF-8, and convert them to proper Java strings in the output routine (i.e. in TYPE). -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2017-03-11 23:19 +0000 |
| Message-ID | <oa20l5$u80$7@dont-email.me> |
| In reply to | #55469 |
Am Mon, 06 Mar 2017 17:16:43 +0000 schrieb Anton Ertl: > Well, the typical description for implementation-defined behaviour in > the standard document is "ambiguous condition", so I would not be > surprised if that's what he means with "ambiguity". That is IMHO actually a problem, and should go away. If it is implementation-defined behavior, it should be named "implementation- defined behavior". Ambiguous is something the implementer himself doesn't know what it will do (e.g. <something> >R EXIT). A quite big number of ambiguous conditions are actually error exits. If the system implements THROW, you will expect it to throw an error code, either one of the standard error codes, or an implementation-defined one, but there is little room for the implementer. We need to define "error condition" in a way that systems without the optional exception wordset could just ABORT, and the others would throw an implementation-defined throw code, and probably get rid of 2/3 of all ambiguous conditions. The big problem with "UB" in the C standard is, that UB can be three things: implementation defined behavior, error condition, and actual ambiguous at run-time. And that the C language lawyers feel free to play Humpty Dumpty on them, and define each as they please (given that one of the prominent compilers using that idea started out as "EGCS" with an egg- style logo might have been an early hint, but we thought the gnu would break out instead of becoming entrapped ;-). We clearly don't want this, but we also want to give the implementers freedom where they need it. This "where they need it" is also an observation: if almost nobody uses these degrees of freedom, drop them. That also means that new concepts like e.g. the recognizers, will need more degrees of freedom initially, and when it turns out that everybody implements them exactly the same way, we can reduce the degrees of freedom. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-03-11 17:01 -1000 |
| Message-ID | <dsidnVZu_-KVJ1nFnZ2dnUU7-R3NnZ2d@supernews.com> |
| In reply to | #55645 |
On 3/11/17 1:19 PM, Bernd Paysan wrote: > Am Mon, 06 Mar 2017 17:16:43 +0000 schrieb Anton Ertl: > >> Well, the typical description for implementation-defined behaviour in >> the standard document is "ambiguous condition", so I would not be >> surprised if that's what he means with "ambiguity". > > That is IMHO actually a problem, and should go away. If it is > implementation-defined behavior, it should be named "implementation- > defined behavior". Ambiguous is something the implementer himself > doesn't know what it will do (e.g. <something> >R EXIT). > > A quite big number of ambiguous conditions are actually error exits. If > the system implements THROW, you will expect it to throw an error code, > either one of the standard error codes, or an implementation-defined one, > but there is little room for the implementer. We need to define "error > condition" in a way that systems without the optional exception wordset > could just ABORT, and the others would throw an implementation-defined > throw code, and probably get rid of 2/3 of all ambiguous conditions. > > The big problem with "UB" in the C standard is, that UB can be three > things: implementation defined behavior, error condition, and actual > ambiguous at run-time. And that the C language lawyers feel free to play > Humpty Dumpty on them, and define each as they please (given that one of > the prominent compilers using that idea started out as "EGCS" with an egg- > style logo might have been an early hint, but we thought the gnu would > break out instead of becoming entrapped ;-). We clearly don't want this, > but we also want to give the implementers freedom where they need it. > This "where they need it" is also an observation: if almost nobody uses > these degrees of freedom, drop them. The issue that you mention re UB in the C standard is precisely the problem that the ANS Forth TC tried to address with the term "ambiguous condition" after hours of wrangling over those three situations, not to mention the fact that some people want to distinguish "errors" from "exceptions" and can explain the difference at great length. You're welcome, of course, to attempt to rewrite Forth 200x with new terminology. It should provide meat for discussions for years. Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-03-12 10:12 +0000 |
| Message-ID | <2017Mar12.111253@mips.complang.tuwien.ac.at> |
| In reply to | #55645 |
Bernd Paysan <bernd@net2o.de> writes:
>Am Mon, 06 Mar 2017 17:16:43 +0000 schrieb Anton Ertl:
>
>> Well, the typical description for implementation-defined behaviour in
>> the standard document is "ambiguous condition", so I would not be
>> surprised if that's what he means with "ambiguity".
>
>That is IMHO actually a problem, and should go away. If it is
>implementation-defined behavior, it should be named "implementation-
>defined behavior".
Actually, the documentation requirements of Forth-94 and Forth-2012
mean that ambiguous conditions are implementation-defined (in the
C-standard sense); see Section 4.1.2. I think that these
documentation requirements don't provide any benefit. And it seems
that I am not the only one: I don't find any trace of the required
documentation in the VFX manual (and I have never missed it). The
SwiftForth and Gforth manuals contain the required documentation, but
that does not mean it provides a benefit.
>Ambiguous is something the implementer himself
>doesn't know what it will do (e.g. <something> >R EXIT).
The implementer certainly knows what <something> >R EXIT does on his
system. The further behaviour (after the EXIT) may depend on the rest
of the environment in addition to the system, but the system
implementor would not need to document the behaviour after the EXIT
even if the documentation requirements required documenting this.
>A quite big number of ambiguous conditions are actually error exits. If
>the system implements THROW, you will expect it to throw an error code,
>either one of the standard error codes, or an implementation-defined one,
>but there is little room for the implementer. We need to define "error
>condition" in a way that systems without the optional exception wordset
>could just ABORT, and the others would throw an implementation-defined
>throw code, and probably get rid of 2/3 of all ambiguous conditions.
Or we make THROW core. The exception wordset was new in 1994, so it
was not made core at the time, but in the meantime it has proven its
value (it may be the most valuable innovation of Forth-94), and there
is no point in contorting ourselves in lots of places just to keep it
optional.
>The big problem with "UB" in the C standard is, that UB can be three
>things: implementation defined behavior, error condition, and actual
>ambiguous at run-time. And that the C language lawyers feel free to play
>Humpty Dumpty on them, and define each as they please
Actually, the language lawyers define each case of undefined behaviour
as "The compiler is allowed to do anything, and that's good for you,
for C, and for the world at large". In earlier time "do anything" was
illustrated with "erase your hard disk", but that was apparently too
much based in reality, so at some point they switched to the "nasal
demon" meme.
>We clearly don't want this,
>but we also want to give the implementers freedom where they need it.
I think this implementor-centric view is what got C into trouble. We
should rather take a more programmer-centric view: How many
programmers want to do the thing that's not standardized (whether
ambiguous or otherwise). What behaviour do those who want to do it
expect? Or do programmers stumble over that behaviour by accident?
In that case, what is the sensible behaviour? Reporting an exception,
or something else?
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-12 07:02 -0500 |
| Message-ID | <CbidnaZIfbN6pVjFnZ2dnUU7-bnNnZ2d@supernews.com> |
| In reply to | #55686 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Bernd Paysan <bernd@net2o.de> writes: >>Am Mon, 06 Mar 2017 17:16:43 +0000 schrieb Anton Ertl: >> >>> Well, the typical description for implementation-defined behaviour in >>> the standard document is "ambiguous condition", so I would not be >>> surprised if that's what he means with "ambiguity". >> >>Ambiguous is something the implementer himself >>doesn't know what it will do (e.g. <something> >R EXIT). > > The implementer certainly knows what <something> >R EXIT does on his > system. The further behaviour (after the EXIT) may depend on the rest > of the environment in addition to the system, but the system > implementor would not need to document the behaviour after the EXIT > even if the documentation requirements required documenting this. That seems to me like a very odd distinction to make. "<something> >R EXIT jumps somewhere. I don't know what effect that code will have" is not significantly different from "I don't know what <something> >R EXIT does." Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-03-12 12:43 +0000 |
| Message-ID | <2017Mar12.134306@mips.complang.tuwien.ac.at> |
| In reply to | #55692 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> The implementer certainly knows what <something> >R EXIT does on his
>> system. The further behaviour (after the EXIT) may depend on the rest
>> of the environment in addition to the system, but the system
>> implementor would not need to document the behaviour after the EXIT
>> even if the documentation requirements required documenting this.
>
>That seems to me like a very odd distinction to make. "<something> >R
>EXIT jumps somewhere. I don't know what effect that code will have"
>is not significantly different from "I don't know what <something> >R
>EXIT does."
For <something> EXECUTE, the system implementor also does not know
what that does because he does not know anything about <something>.
The programmer, OTOH, knows what <something> is, and therefore knows
what <something> EXECUTE does, and what <something> >R EXIT does if
what the system works the way the programmer had in mind (probably a
jump to <something>).
You often show off your debate-club experience by throwing names of
rethoric tricks around instead of providing a proper argument. One of
the names you have thrown around repeatedly is "slippery slope". This
kind of thing is where we have seen GCC and Clang really slipping down
the slope right to the bottom, e.g., the compiler "optimizing" a
counted loop into an endless loop, because the compiler maintainers
think that it is not "significantly different" from performing an
out-of-bounds array read whose result is not used.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-12 12:28 -0500 |
| Message-ID | <aLqdnUlsN47JGFjFnZ2dnUU7-eXNnZ2d@supernews.com> |
| In reply to | #55696 |
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 implementer certainly knows what <something> >R EXIT does on his >>> system. The further behaviour (after the EXIT) may depend on the rest >>> of the environment in addition to the system, but the system >>> implementor would not need to document the behaviour after the EXIT >>> even if the documentation requirements required documenting this. >> >>That seems to me like a very odd distinction to make. "<something> >R >>EXIT jumps somewhere. I don't know what effect that code will have" >>is not significantly different from "I don't know what <something> >R >>EXIT does." > > For <something> EXECUTE, the system implementor also does not know > what that does because he does not know anything about <something>. I agree. > The programmer, OTOH, knows what <something> is, and therefore knows > what <something> EXECUTE does, and what <something> >R EXIT does if > what the system works the way the programmer had in mind (probably a > jump to <something>). On some systems, it might be that it has the same effect as EXECUTE . On other systems it might be that the return stack is used in other ways, and might do something that it less easy for an implementer to predict. For example, on a system which uses base-relative offsets for XTs but keeps absolute addresses on the return stack, all the implementer knows is that the system will go into the weeds. Boldly to say that an implementer certainly knows what it will do is too much of a stretch. > You often show off your debate-club experience by throwing names of > rethoric tricks around instead of providing a proper argument. One > of the names you have thrown around repeatedly is "slippery slope". What on earth did I do, beyond disagree with you, to justify such aggression? I'm not going to respond to baseless attacks with no context. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-03-12 16:29 +0100 |
| Message-ID | <oa3pgp$52p$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #55686 |
In article <2017Mar12.111253@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >Bernd Paysan <bernd@net2o.de> writes: >>Am Mon, 06 Mar 2017 17:16:43 +0000 schrieb Anton Ertl: >> >>> Well, the typical description for implementation-defined behaviour in >>> the standard document is "ambiguous condition", so I would not be >>> surprised if that's what he means with "ambiguity". >> >>That is IMHO actually a problem, and should go away. If it is >>implementation-defined behavior, it should be named "implementation- >>defined behavior". > >Actually, the documentation requirements of Forth-94 and Forth-2012 >mean that ambiguous conditions are implementation-defined (in the >C-standard sense); see Section 4.1.2. I think that these >documentation requirements don't provide any benefit. And it seems >that I am not the only one: I don't find any trace of the required >documentation in the VFX manual (and I have never missed it). The >SwiftForth and Gforth manuals contain the required documentation, but >that does not mean it provides a benefit. > >>Ambiguous is something the implementer himself >>doesn't know what it will do (e.g. <something> >R EXIT). > >The implementer certainly knows what <something> >R EXIT does on his >system. The further behaviour (after the EXIT) may depend on the rest >of the environment in addition to the system, but the system >implementor would not need to document the behaviour after the EXIT >even if the documentation requirements required documenting this. > >>A quite big number of ambiguous conditions are actually error exits. If >>the system implements THROW, you will expect it to throw an error code, >>either one of the standard error codes, or an implementation-defined one, >>but there is little room for the implementer. We need to define "error >>condition" in a way that systems without the optional exception wordset >>could just ABORT, and the others would throw an implementation-defined >>throw code, and probably get rid of 2/3 of all ambiguous conditions. > >Or we make THROW core. The exception wordset was new in 1994, so it >was not made core at the time, but in the meantime it has proven its >value (it may be the most valuable innovation of Forth-94), and there >is no point in contorting ourselves in lots of places just to keep it >optional. This doesn't help. THROW is core in ciforth as core as it gets. Now if you type 1 0 / you get a crash and linux says "memory fault core dumped " "floating point exception " or some such. That is an ambigeous condition. If you you put the requirement that this must end in an ABORT that means that the Forth must be able to use the Linux exception mechanism. For simple Forth's that is a heavy burden for almost no benefit, to help out with an incorrect Forth program. In the example of ciforth, you can do INSTALL-TRAPS in lina32, this will be caught, and it results in a warm start. You can't do INSTALL-TRAPS in lina64 because I couldn't figure it out in a reasonable amount of time. The trap mechanism is virtually undocumented on the system call level, one has to go through a c-library. It is a resident library, so it requires implementing a read shared libraries mechanism. Analysing the c code stopped for me when I had manage to generate a 1 Megabyte assembler file after a static linking. Somewhere the mechanism to use traps is hidden in there. In the world of micro controllers it is even worse. You divide by zero, your computer gets bezerk, get over it. You don't know what happens, you don't care what happens, because you know for sure that it is a mistake. That is "ambigeous condition" for you. > >>The big problem with "UB" in the C standard is, that UB can be three >>things: implementation defined behavior, error condition, and actual >>ambiguous at run-time. And that the C language lawyers feel free to play >>Humpty Dumpty on them, and define each as they please > >Actually, the language lawyers define each case of undefined behaviour >as "The compiler is allowed to do anything, and that's good for you, >for C, and for the world at large". In earlier time "do anything" was >illustrated with "erase your hard disk", but that was apparently too >much based in reality, so at some point they switched to the "nasal >demon" meme. This is somewhat misrepresenting it. You must never have an UB in your program. (Unless your compiler vendor guarantees a specific behaviour in the specific circumstances you're in.) So as far as the "how to program" part is concerned, there is nothing ambiguous about ambiguous conditions. Don't do that. > >>We clearly don't want this, >>but we also want to give the implementers freedom where they need it. > >I think this implementor-centric view is what got C into trouble. We >should rather take a more programmer-centric view: How many >programmers want to do the thing that's not standardized (whether >ambiguous or otherwise). What behaviour do those who want to do it >expect? Or do programmers stumble over that behaviour by accident? >In that case, what is the sensible behaviour? Reporting an exception, >or something else? I don't think that C is "in trouble" in the first place. Nothing compared to Syria or the USA. > >- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-03-12 16:16 +0000 |
| Message-ID | <2017Mar12.171647@mips.complang.tuwien.ac.at> |
| In reply to | #55703 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>Now if you type 1 0 / you get a crash and linux says
>"memory fault core dumped "
>"floating point exception "
>or some such.
>That is an ambigeous condition. If you you put the requirement that
>this must end in an ABORT that means that the Forth must be able to
>use the Linux exception mechanism. For simple Forth's that is a
>heavy burden for almost no benefit, to help out with
>an incorrect Forth program.
I disagree about the burden and the benefit, but in any case, there is
also this:
[arm64:~/nfstmp/gforth-arm64:2053] gforth-fast
Gforth 0.7.9_20160804, Copyright (C) 1995-2016 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
1 0 / . 0 ok
That's pretty much the raw signed division operation on ARM64. If the
Forth standard required to throw an error on division by zero,
gforth-fast would test the divisor and if 0, perform the THROW. The
cost? Relatively small, possibly 0 if we do the check while the
divide unit is working on the division. Gforth does that (and also
checking for minint/-1) in its debugging engine.
Anyway, either this is one of the cases that should produce a THROW
(then we add the check), or it is one of the other cases (then we
don't).
>In the world of micro controllers it is even worse. You divide
>by zero, your computer gets bezerk, get over it.
Really? Which microcontroller behaves that way?
>You don't know what happens, you don't care what happens, because
>you know for sure that it is a mistake. That is "ambigeous condition"
>for you.
Nonsense. And this division by zero case is a very good example for
that.
If I want to define a THROWing / from a / that produces a (bogus)
result (like the ARM64 hardware divider), the straightforward way to
do it is:
: / ( n1 n2 -- n3 )
dup 0= -10 and throw / ;
This incurs the cost of first testing the divisor, and then doing the
division, i.e., these operations are performed sequentially. An
alternative is to test the divisor in parallel with doing the
division, by starting the division, and then doing the check while it
works:
: / ( n1 n2 -- n3 )
dup >r / r> 0= -10 and throw ;
For that to work I very much care what happens: The latter version
needs a / that finishes and produces a result even on division by zero
instead of, say, ending the process. So even though a division by
zero is usually a bug in an application program, it is important what
happens.
>>>The big problem with "UB" in the C standard is, that UB can be three
>>>things: implementation defined behavior, error condition, and actual
>>>ambiguous at run-time. And that the C language lawyers feel free to play
>>>Humpty Dumpty on them, and define each as they please
>>
>>Actually, the language lawyers define each case of undefined behaviour
>>as "The compiler is allowed to do anything, and that's good for you,
>>for C, and for the world at large". In earlier time "do anything" was
>>illustrated with "erase your hard disk", but that was apparently too
>>much based in reality, so at some point they switched to the "nasal
>>demon" meme.
>
>This is somewhat misrepresenting it. You must never have an UB in your
>program.
Where do you see the misrepresentation? Are you claiming that no C
language lawyer ever said anything about "erase your hard disk" or
"nasal demon"?
>So as far as the "how to
>program" part is concerned, there is nothing ambiguous about
>ambiguous conditions. Don't do that.
I am certain to never "do" an ambiguous condition on ciforth, simply
by not using ciforth, ever. If the C compiler maintainers want to
destroy C with this kind of thinking, that's sad, but could be an
opportunity for Forth. But we don't need this in Forth.
>I don't think that C is "in trouble" in the first place.
>Nothing compared to Syria or the USA.
Will C survive longer than Syria and the USA? I would bet against C.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-12 21:42 +0000 |
| Message-ID | <oa4f7n$r66$1@dont-email.me> |
| In reply to | #55686 |
On 3/12/2017 10:12, Anton Ertl wrote: >> A quite big number of ambiguous conditions are actually error exits. If >> the system implements THROW, you will expect it to throw an error code, >> either one of the standard error codes, or an implementation-defined one, >> but there is little room for the implementer. We need to define "error >> condition" in a way that systems without the optional exception wordset >> could just ABORT, and the others would throw an implementation-defined >> throw code, and probably get rid of 2/3 of all ambiguous conditions. > Or we make THROW core. The exception wordset was new in 1994, so it > was not made core at the time, but in the meantime it has proven its > value (it may be the most valuable innovation of Forth-94), and there > is no point in contorting ourselves in lots of places just to keep it > optional. > Seconded. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-03-08 19:13 +1100 |
| Message-ID | <o9oeao$5dl$1@gioia.aioe.org> |
| In reply to | #55446 |
Mark Wills wrote: > Being a supporter of the effort to move towards a standard is plain common > sense. > ... You have a locals implementation that is clearly neither ANS nor 200x. Would that be a failure of common sense, or a failure of the standard?
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-03-08 01:33 -0800 |
| Message-ID | <e66489d4-e739-4974-8f56-b92d2f4451a1@googlegroups.com> |
| In reply to | #55527 |
On Wednesday, 8 March 2017 08:11:07 UTC, HAA wrote: > Mark Wills wrote: > > Being a supporter of the effort to move towards a standard is plain common > > sense. > > ... > > You have a locals implementation that is clearly neither ANS nor 200x. > Would that be a failure of common sense, or a failure of the standard? Neither. My system isn't ANS. It's Forth 83. Forth 83 doesn't have locals, so I'm free to implement them any way I damn well like. So there. And in any case, my implementation (IMO - YMMV etc.) has one advantage over the ANS way, which I can't be bothered to go into here.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-03-10 10:37 +1100 |
| Message-ID | <o9sos1$1m7t$1@gioia.aioe.org> |
| In reply to | #55533 |
Mark Wills wrote: > On Wednesday, 8 March 2017 08:11:07 UTC, HAA wrote: > > Mark Wills wrote: > > > Being a supporter of the effort to move towards a standard is plain common > > > sense. > > > ... > > > > You have a locals implementation that is clearly neither ANS nor 200x. > > Would that be a failure of common sense, or a failure of the standard? > > Neither. My system isn't ANS. It's Forth 83. Forth 83 doesn't have locals, > so I'm free to implement them any way I damn well like. > > So there. > > And in any case, my implementation (IMO - YMMV etc.) has one advantage over > the ANS way, which I can't be bothered to go into here. That doesn't sound like supporting the effort to move toward a standard. It sounds more like doing what you 'damn well like'. While I wouldn't put it that way or use those words, I'm not in disagreement. Forth is founded on choice, not compliance.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-04 18:35 -0800 |
| Message-ID | <fde2a361-4aa3-48be-b514-33e101389b6c@googlegroups.com> |
| In reply to | #55230 |
On Monday, February 27, 2017 at 11:55:15 PM UTC-7, Paul Rubin wrote: > "HAA" <someone@microsoft.com> writes: > > You talk about 'what the Forth community wants'. If it wanted a > > standard then I'd expect Forth Inc users to be banging on the door > > demanding 200x be implemented. ANS-Forth became the standard for Forth in 1994 and there was no implementation until 1997 when Forth Inc. hired Rick van Norman to write SwiftForth, but SwiftForth was so bug-ridden as to be unusable until version-3 came out several years later. So, no Forth users were "banging on the door demanding ANS-Forth to be implemented" either --- ANS-Forth was just a marketing gimmick from Forth Inc. with the sole purpose of convincing the world that Forth Inc. leads the entire Forth community --- ANS-Forth didn't have to actually work or make sense to accomplish this goal. > Is 200x a standard rather than a draft of one? Is the Forth community > satisfied that it already has a standard (ANS) with 200x being a > refinement, like more recent iterations of the C standard? Forth-200x is just a marketing gimmick from Forth Inc. with the sole purpose of convincing the world that Forth Inc. leads the entire Forth community --- Forth-200x doesn't have to acxtually work or make sense to accomplish this goal --- all that is needed is for the Forth-200x mailing list to collect the names of "supporters" so Elizabeth Rather the name-dropper can claim that they believe in her totally. Questions such as Paul Rubin's above are just brown-nosing of Elizabeth Rather. His use of the word "refinement" implies that ANS-Forth had technical merit to start with, which isn't true --- a marketing gimmick has zero technical merit --- refining ANS-Forth with Forth-200x is just piling more manure on top of an already big pile. Actually improving ANS-Forth will kill ANS-Forth because doing so shines a spotlight on the stupidity of ANS-Forth. My disambiguifiers, for example, allow me to write code such as SYNONYM ALIAS and an early-binding MACRO: that were impossible without the disambiguifiers. Disambiguifying FIND just shines a spotlight on the fact that FIND in ANS-Forth is ambiguous. How could Elizabeth Rather be so stupid as to screw up FIND which should be simple to understand and trivial to implement? She is not a programmer at all --- for her, simple ideas are mind-boggling complicated and have to be defined in an ambiguous manner. By writing ANS-Forth code, I'm killing ANS-Forth. Anybody with one year of programming experience can guffaw at Elizabeth Rather's idiotic pronouncements about programming (she hates code-libraries, she doesn't believe that reusable code is possible anyway, and she uses global variables for communicating between functions because she doesn't know what re-entrancy is). But she dismisses everybody who guffaws at her idiocy by saying that they have never programmed in Forth and don't understand the "Forth Way" --- she tried to dismiss me in 2009 like this --- I write a lot of ANS-Forth code, and I work around her idiotic rules to do so, so when I say that ANS-Forth is crap then this carries some weight. ANS-Forth is just a big steaming pile of salesmanship --- press the flush lever --- relieve the Forth community of Elizabeth Rather's awful stench.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-02-27 23:12 -0800 |
| Message-ID | <61b25d60-1436-4c36-91f0-76dc73292c02@googlegroups.com> |
| In reply to | #55223 |
On Monday, February 27, 2017 at 6:52:26 PM UTC-7, Elizabeth D. Rather wrote: > On 2/27/17 12:22 AM, Mark Wills wrote: > > Reading the speech/document, I come away with the impression that as much > > as I admire him, and as much as he seems to be a very pleasant person on > > a personal level, I think he must have been a very difficult person to work > > with! > > I suspect all geniuses are, to some extent. Indeed, Chuck was wonderful > in some respects and difficult in others. He had a unique POV. He could > never bring himself to reuse any code, for example: he treasured his > past code (e.g., math functions, graphics package, etc.) but > continuously rewrote them. Most of us couldn't live/work that way. And > we very much want to be able to share code and reuse it. You are the same person who said: ------------------------------------------------------------------------------------- Does "*every* application" you write use exactly the same kind of data arranged in the same way? If so, having written it once you can reuse it often. If not, you either have to rearrange your data to make it work or modify your "general-purpose" structure. ------------------------------------------------------------------------------------- You do not: "very much want to be able to share code and reuse it." You don't understand how this is accomplished. > So, there's no way that any standard could ever work for Chuck, but that > doesn't mean a standard isn't extremely valuable for the Forth community > that wants to reuse and share code, and for managers who want a > reasonably stable language for their products. The goal with Straight Forth is that it will support code-libraries --- quotations that access the parent function's local variables are crucial for this --- that is what Paul Rubin asks for: "the gain." Whether this would work for Charles Moore or not, I don't know. Elizabeth Rather claims to be able to speak for "Chuck" --- she is a liar and a name-dropper though --- unless he comes out and specifically speaks against code-libraries, I won't worry about it. Actually, I won't worry about it even if he does, because code-libraries are obviously crucial for a language to be successful --- the lack of support for code libraries is why Forth has failed.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-02-27 13:13 +0000 |
| Message-ID | <o918i0$j88$1@dont-email.me> |
| In reply to | #55143 |
On 2/27/2017 02:15, HAA wrote: > Alex wrote: >> On 2/26/2017 03:29, HAA wrote: >>> Albert van der Horst wrote: >>>> In article >>>> <80bac9cc-dba0-430a-9a09-9d478e1e8f9f@googlegroups.com>, Mark >>>> Wills <markwills1970@gmail.com> wrote: >>>>> Who are the guardian angels? Anyone here? My experience with >>>>> Wikipedia has not been good. In my experience the subjects in >>>>> which I had knowledge and experience were 'guarded' by what >>>>> can only be described as zealots who think they know better >>>>> than everyone else. >>>> >>>> Please restrict to 72 char's. >>>> >>>> You mean you contributed something important, then it was >>>> subsequently deleted by a wikibobo? Yes that can be a problem, >>>> but let it not deter you. To be honest the times that happened >>>> to me, the contribution was a bit dubious. >>>> >>>> Groetjes Albert >>> >>> Scrutiny is needed else the result is ignorant or biased >>> statements e.g. >>> >>> "... de facto standards FORTH-79 and FORTH-83 ... were unified by >>> ANSI in 1994" >>> >>> In mentioning standards as part of Forth's history, is it not >>> incumbent to mention their contentiousness in a language designed >>> to be user-alterable. >>> >>> Chuck Moore: "It is impossible for one version of Forth to >>> subsume all possible opportunities. Forth is larger than the >>> standard." >>> >>> >> >> Chuck Moore actually said: "It is impossible for one version of >> Forth to subsume all possible opportunities. Forth is larger than >> the standard. *I think ANS Forth will become the dominant >> dialect.*" (my emphasis). >> >> And: "I think an ANSI standard is relevant now, so that you can >> have a program written on one personal computer and run it on >> another... The standard as a documentation and communication >> language is a laudable goal...a useful tool that we've never had." > > It was a farewell speech given in apology for having walked out on > the ANS TC. He made it as gracious as possible. In the years since > Chuck hasn't minced words. ANS was the latest but it's all standards > he has a problem with: > > "I distrust formal representations. For example, the ANSII Forth > standard does not describe Forth, but a language with the same > name." "The first meetings were pleasant, because there was nothing of substance. But the principle I cannot subscribe to is that matters of fact or truth or beauty can be voted on. The facts speak for themselves. That's my gut reaction." Mystics and those who ascribe to truths beyond understanding are often unable to describe what they feel; hence he says, your Forth is not his Forth, for its beauty and self evident facts cannot be described or contained by words. What an annoying git he must have been. I can imagine the relief when he walked out, and the patience and tongue biting required by the committee when he came back and graciously shat on their work. > > The Wikipedia article would have everyone believe otherwise. > The wikipedia article cares as little for Charles Moores' gut feeling as I do. I simply wanted to make sure you understood that quoting his position required a little more of what he said than your truncated quote. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-02-27 23:28 -0800 |
| Message-ID | <7c00e582-1740-4a29-bcd7-b4865ae9ea47@googlegroups.com> |
| In reply to | #55179 |
On Monday, February 27, 2017 at 6:13:25 AM UTC-7, Alex wrote: > On 2/27/2017 02:15, HAA wrote: > > It was a farewell speech given in apology for having walked out on > > the ANS TC. He made it as gracious as possible. In the years since > > Chuck hasn't minced words. ANS was the latest but it's all standards > > he has a problem with: > > > > "I distrust formal representations. For example, the ANSII Forth > > standard does not describe Forth, but a language with the same > > name." > > "The first meetings were pleasant, because there was nothing of > substance. But the principle I cannot subscribe to is that matters of > fact or truth or beauty can be voted on. The facts speak for > themselves. That's my gut reaction." I don't think Charles Moore would be opposed to my Straight Forth standard. He would be opposed if I claimed that this was the Forth standard to end all Forth standards. I don't though. I only want it to support code-libraries (has real quotations, not Paysan-faked quotations), and supports numeric programming (has ratios), and supports text handling (has a string-stack with copy-on-write). Straight Forth does not support multi-core computers, which Oforth does support --- multi-core computers are the future (actually, the present, although they are not well-supported yet) --- so, Straight Forth is not really aiming to be the last Forth standard; there will have to be another Forth standard in the future that supports multi-core computers, but I'm not delving into that at this time (somewhat beyond my level of expertise). > Mystics and those who ascribe to truths beyond understanding are often > unable to describe what they feel; hence he says, your Forth is not his > Forth, for its beauty and self evident facts cannot be described or > contained by words. > > What an annoying git he must have been. I can imagine the relief when he > walked out, and the patience and tongue biting required by the committee > when he came back and graciously shat on their work. > > > The Wikipedia article would have everyone believe otherwise. > > The wikipedia article cares as little for Charles Moores' gut feeling as > I do. I simply wanted to make sure you understood that quoting his > position required a little more of what he said than your truncated quote. What an annoying git you are! You truncated his quote too, for the purpose of making it seem as if he whole-heartedly supported ANS-Forth as the Forth standard to end all Forth standards --- quite a contorted interpretation, considering that this speech was his farewell to ANS-Forth. Charles Moore didn't want sycophants --- you hate him because you know that he had no use for your kind --- you love Elizabeth Rather because she wants (actually needs) sycophants and hence gives your otherwise meaningless life a purpose. You said that you: "do standards for a living." LOL You are a corporate shill!
[toc] | [prev] | [next] | [standalone]
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web