Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #17381 > unrolled thread
| Started by | Chris Hinsley <chris.hinsley@gmail.com> |
|---|---|
| First post | 2012-11-19 16:03 +0000 |
| Last post | 2012-11-29 11:47 -0800 |
| Articles | 20 on this page of 180 — 34 participants |
Back to article view | Back to comp.lang.forth
why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-19 16:03 +0000
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-19 16:06 +0000
Re: why bother with standards ? daveyrotten <danw8804@gmail.com> - 2012-11-19 08:15 -0800
Re: why bother with standards ? rickman <gnuarm@gmail.com> - 2012-11-19 12:07 -0500
Re: why bother with standards ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-20 02:27 +0100
Re: why bother with standards ? Winston19842005 <winston19842005@yahoo.com> - 2012-11-19 21:59 -0500
Re: why bother with standards ? Jason Damisch <jasondamisch@yahoo.com> - 2012-11-19 19:21 -0800
Re: why bother with standards ? Mark Wills <forthfreak@gmail.com> - 2012-11-20 01:33 -0800
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-20 05:09 -0600
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-20 18:48 -0800
Re: why bother with standards ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-20 09:49 +0000
Re: why bother with standards ? Pablo Hugo Reda <pabloreda@gmail.com> - 2012-11-19 10:59 -0800
Re: why bother with standards ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-19 19:06 -0500
Re: why bother with standards ? "Elizabeth D. Rather" <erather@forth.com> - 2012-11-19 14:25 -1000
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-19 20:29 -0800
Re: why bother with standards ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-20 05:42 -0500
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-20 17:23 +0000
Re: why bother with standards ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-20 21:05 -0500
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-21 14:24 +0000
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-20 18:24 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-20 03:07 -0800
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-20 17:35 +0000
Re: why bother with standards ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-20 21:02 -0500
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-21 02:04 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-20 19:21 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-21 01:34 -0800
Re: why bother with standards ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-21 04:51 -0500
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-21 04:43 -0600
Re: why bother with standards ? Fritz Wuehler <fritz@spamexpire-201211.rodent.frell.theremailer.net> - 2012-11-21 20:34 +0100
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-21 12:04 -0800
Re: why bother with standards ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-22 21:19 -0500
Re: why bother with standards ? Mark Wills <forthfreak@gmail.com> - 2012-11-23 02:05 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-23 03:05 -0800
Re: why bother with standards ? Mark Wills <forthfreak@gmail.com> - 2012-11-23 03:22 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-23 12:13 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-23 12:24 -0800
Re: why bother with standards ? "Elizabeth D. Rather" <erather@forth.com> - 2012-11-23 10:43 -1000
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-23 15:10 -0600
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-23 13:40 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-23 13:44 -0800
Re: why bother with standards ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-24 01:29 +0100
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-24 04:54 -0600
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-24 16:56 -0800
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-25 04:16 -0600
Re: why bother with standards ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-26 14:48 +0000
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-23 09:12 -0600
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-23 22:00 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-23 03:52 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-23 07:34 -0800
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-23 09:57 -0600
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-23 20:09 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-24 04:53 -0800
Re: why bother with standards ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-24 14:32 +0100
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-24 21:01 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-25 02:22 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-25 02:27 -0800
Re: why bother with standards ? awegel@arcor.de (Alex Wegel) - 2012-11-23 19:12 +0100
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-23 22:39 -0800
Re: why bother with standards ? awegel@arcor.de (Alex Wegel) - 2012-11-24 16:54 +0100
Re: why bother with standards ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-25 05:09 -0500
Re: why bother with standards ? mhx@iae.nl (Marcel Hendrix) - 2012-11-25 13:33 +0200
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-24 12:20 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-24 20:45 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-25 02:21 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-21 14:38 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-21 18:17 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-23 04:26 -0800
Re: why bother with standards ? Ron Aaron <rambamist@gmail.com> - 2012-11-23 15:28 +0200
Re: why bother with standards ? awegel@arcor.de (Alex Wegel) - 2012-11-21 17:29 +0100
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-20 17:21 +0000
Re: why bother with standards ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-21 13:00 +0000
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-21 14:31 +0000
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-21 17:41 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-21 20:33 -0800
Re: why bother with standards ? Mark Humphries <mwh@intranetsys.com> - 2012-11-22 10:00 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-22 17:16 -0800
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-20 17:12 +0000
Re: why bother with standards ? Josh Grams <josh@qualdan.com> - 2012-11-20 17:30 +0000
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-20 17:48 +0000
Re: why bother with standards ? Andy Valencia <vandys@vsta.org> - 2012-11-20 19:40 +0000
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-20 19:50 +0000
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-20 15:41 -0800
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-21 14:43 +0000
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-21 08:46 -0800
Re: why bother with standards ? Brad Eckert <hwfwguy@gmail.com> - 2012-11-20 14:09 -0800
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-24 10:41 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-24 11:37 -0800
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-24 22:32 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-25 07:54 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-25 17:02 -0800
Re: why bother with standards ? "Elizabeth D. Rather" <erather@forth.com> - 2012-11-25 16:20 -1000
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-25 19:44 -0800
Re: why bother with standards ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-26 14:59 +0000
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-26 11:37 -0800
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-26 13:05 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-26 15:29 -0800
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-26 16:38 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-26 19:37 -0800
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-26 20:29 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-26 22:22 -0800
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-26 23:03 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-27 01:09 -0800
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-27 08:52 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-27 10:43 -0800
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-27 12:01 -0600
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-28 23:37 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-29 00:00 -0800
Re: why bother with standards ? "Elizabeth D. Rather" <erather@forth.com> - 2012-11-28 22:13 -1000
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-29 01:11 -0800
Re: why bother with standards ? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-11-29 11:00 +0000
Re: why bother with standards ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-29 18:58 +0100
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-29 12:51 -0800
Re: why bother with standards ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-30 00:42 +0100
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-29 19:57 -0800
Re: why bother with standards ? Mark Wills <forthfreak@gmail.com> - 2012-11-30 02:22 -0800
Re: why bother with standards ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-30 18:47 +0100
Re: why bother with standards ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-30 12:53 +0000
Re: why bother with standards ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-30 18:33 +0100
Debuggers (Re: why bother with standards ?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-29 13:44 +0000
Re: Debuggers (Re: why bother with standards ?) Paul Rubin <no.email@nospam.invalid> - 2012-11-29 09:36 -0800
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-29 06:01 -0600
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-29 10:00 -0800
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-29 12:22 -0600
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-29 10:38 -0800
Re: why bother with standards ? Coos Haak <chforth@hccnet.nl> - 2012-11-29 21:13 +0100
Re: why bother with standards ? "Elizabeth D. Rather" <erather@forth.com> - 2012-11-29 17:11 -1000
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-30 03:37 -0600
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-30 02:11 -0800
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-30 05:24 -0600
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-30 11:23 -0800
Re: why bother with standards ? the_gavino_himself <visphatesjava@gmail.com> - 2012-11-29 21:16 -0800
Re: why bother with standards ? "Elizabeth D. Rather" <erather@forth.com> - 2012-11-29 08:38 -1000
Re: why bother with standards ? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-29 18:43 +0000
Re: why bother with standards ? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-29 12:15 +0000
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-29 09:23 -0800
Re: why bother with standards ? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-29 18:24 +0000
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-29 11:06 -0800
Re: why bother with standards ? "Elizabeth D. Rather" <erather@forth.com> - 2012-11-29 17:35 -1000
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-29 22:37 -0800
Re: why bother with standards ? "Elizabeth D. Rather" <erather@forth.com> - 2012-11-29 21:08 -1000
Re: why bother with standards ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-30 17:41 +0100
Re: why bother with standards ? "Elizabeth D. Rather" <erather@forth.com> - 2012-11-30 08:43 -1000
Re: why bother with standards ? Mark Wills <forthfreak@gmail.com> - 2012-11-30 02:30 -0800
Re: why bother with standards ? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-30 10:40 +0000
Re: why bother with standards ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-30 14:03 +0000
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-30 14:06 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-30 14:51 -0800
Re: why bother with standards ? Howerd <howerdo@yahoo.co.uk> - 2012-11-30 14:58 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-12-02 18:02 -0800
Re: why bother with standards ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-03 16:34 +0100
Re: why bother with standards ? Coos Haak <chforth@hccnet.nl> - 2012-12-03 21:39 +0100
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-12-03 14:49 -0800
Re: why bother with standards ? Brad Eckert <hwfwguy@gmail.com> - 2012-12-05 09:24 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-12-05 11:26 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-12-05 11:39 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-12-05 15:32 -0800
Re: why bother with standards ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-12-05 20:57 -0500
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-12-05 18:55 -0800
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-12-05 20:01 -0800
Re: why bother with standards ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-12-06 19:05 -0500
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-12-06 16:14 -0800
Re: why bother with standards ? Bill Marcum <bill@nowhere.invalid> - 2012-12-07 20:13 -0500
Re: why bother with standards ? Brad Eckert <hwfwguy@gmail.com> - 2012-12-03 14:29 -0800
Re: why bother with standards ? Mark Wills <forthfreak@gmail.com> - 2012-11-30 02:20 -0800
Re: why bother with standards ? Doug Hoffman <glidedog@gmail.com> - 2012-11-30 06:52 -0500
Re: why bother with standards ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-29 19:12 +0100
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-29 14:55 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-26 22:01 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-27 01:44 -0800
Re: why bother with standards ? "Ed" <invalid@nospam.com> - 2012-11-21 12:40 +1100
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-21 14:51 +0000
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-21 19:24 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-21 21:54 -0800
Re: why bother with standards ? The Beez <the.beez.speaks@gmail.com> - 2012-11-24 08:03 -0800
Re: why bother with standards ? "Ed" <invalid@nospam.com> - 2012-11-30 14:45 +1100
Re: why bother with standards ? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-30 10:48 +0000
Re: why bother with standards ? "Ed" <invalid@nospam.com> - 2012-12-04 03:52 +1100
Re: why bother with standards ? The Beez <the.beez.speaks@gmail.com> - 2012-12-06 10:34 -0800
Re: why bother with standards ? The Beez <the.beez.speaks@gmail.com> - 2012-12-06 10:37 -0800
Re: why bother with standards ? the_gavino_himself <visphatesjava@gmail.com> - 2012-11-29 11:47 -0800
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-11-29 06:01 -0600 |
| Message-ID | <oJydnY89Q4ks0yrNnZ2dnUVZ8imdnZ2d@supernews.com> |
| In reply to | #17661 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >> Embedded programming wasn't harder for me. Guess why? I had Forth! >> Extensibility (to add tracing easily) and interactivity make a huge >> difference. You certainly don't need hardware debuggers unless that's >> the only way to get your program into the device. > > I remember wanting a hardware debugger to deal with a problem of > intermittent memory corruption (certain locations getting clobbered > and we couldn't figure out why) and the CPU didn't have hardware > watchpoints (that would have found the problem instantly). Y'know what? It's terribly easy to add watchpoints if you have Forth. You can do it at every word, at every enter and exit, or at every store. Ten minutes, tops. > A software debugger with breakpoints would have helped, but we > didn't have that either, so we ended up having to rebuild the > software with tracing and reload/boot the box dozens of times in > order to close in on the problem. Well, yes. But if you had Forth... > I've also generally found source-level single step debuggers (gdb) > invaluable even for just trying to understand code that works (as > opposed to diagnosing buggy code). If I want to figure out what > some chunk of obscure code is doing, it's far more enlightening to > breakpoint at the beginning of it and step through it with gdb, than > to try to grok its operation by pure eyeballing of the code. For > reverse engineering (though I haven't done much of that) I'm sure > it's an even bigger help. Me too, when I don't have Forth. I use GDB for about 6 hours a day... > If the embedded target supports this stuff, then great, but > otherwise it's a big slowdown not to have it. No, it isn't, if you have Forth. (I'm sorry to be boring, but there it is.) Forth is at its very best in an embedded environment. Several shops to my knowledge have used Forth purely as a hardware test and debugging environment, because it's such a nice interactive environment. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-29 10:00 -0800 |
| Message-ID | <7xk3t4i90n.fsf@ruckus.brouhaha.com> |
| In reply to | #17687 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > Y'know what? It's terribly easy to add watchpoints if you have Forth. > You can do it at every word, at every enter and exit, or at every > store. Ten minutes, tops. I couldn't imagine that project using any Forth other than VFX, since they were obsessed (in a bad way) with code optimization. Is it as easy to redefine basic operations like ! in VFX's native code generator as it is in a typical threaded interpreter? Als, the code was full of crufty micro-optimizations in lots of places where it didn't matter, but in some places it probably actually did matter (some hardware in the box had real-time requirements). So slowing down every store for the purpose of adding software watchpoints might have messed up the box's operation. In this particular incident the box had a lot of C code and a little bit of assembly code, and the bug (stray pointer) turned out to be in the assembly code (it took a long while to figure this out). If the C were Forth instead but the bug was still in assembly, then software Forth watchpoints wouldn't have found the bug like a hardware watchpoint would have. It might still have eliminated other possibilities more quickly than what we did, of course. For reasons I mentioned in another post though, I think programming this box in Forth would have resulted in even bigger headaches than the C code had. Erlang would probably have made more sense than either. > Me too, when I don't have Forth. I use GDB for about 6 hours a day... I'd be interested in seeing some kind of development/debugging session (maybe on video) by a good Forth programmer sometime, to see what they do differently from what C programmers do. Sam Falvo has some videos like that so I may try to download one and watch it.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-11-29 12:22 -0600 |
| Message-ID | <so2dnd_ieIxuOirNnZ2dnUVZ8gSdnZ2d@supernews.com> |
| In reply to | #17702 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> Y'know what? It's terribly easy to add watchpoints if you have Forth. >> You can do it at every word, at every enter and exit, or at every >> store. Ten minutes, tops. > > I couldn't imagine that project using any Forth other than VFX, > since they were obsessed (in a bad way) with code optimization. Is > it as easy to redefine basic operations like ! in VFX's native code > generator as it is in a typical threaded interpreter? Sure, you just redefine ! and load your program. You might have to redefine a bunch of other words as well. Also, while you're at it, you might as well redefine ; . > Als, the code was full of crufty micro-optimizations in lots of > places where it didn't matter, but in some places it probably > actually did matter (some hardware in the box had real-time > requirements). So slowing down every store for the purpose of > adding software watchpoints might have messed up the box's > operation. Perhaps. I've been there. > For reasons I mentioned in another post though, I think programming > this box in Forth would have resulted in even bigger headaches than > the C code had. Erlang would probably have made more sense than > either. > >> Me too, when I don't have Forth. I use GDB for about 6 hours a day... > > I'd be interested in seeing some kind of development/debugging > session (maybe on video) by a good Forth programmer sometime, to see > what they do differently from what C programmers do. Sam Falvo has > some videos like that so I may try to download one and watch it. Well, the tracing example above is pretty typical. Also, things like conditional breakpoints don't really have much of a place if your edit/compile cycle is a couple of seconds. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-29 10:38 -0800 |
| Message-ID | <7xwqx445lz.fsf@ruckus.brouhaha.com> |
| In reply to | #17704 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> it as easy to redefine basic operations like ! in VFX's native code >> generator as it is in a typical threaded interpreter? > Sure, you just redefine ! and load your program. That won't interfere with the compiler? Plus of course doing such redefinitions requires knowing the machine language of the target box, and I wasn't really familiar with that. > Well, the tracing example above is pretty typical. Also, things like > conditional breakpoints don't really have much of a place if your > edit/compile cycle is a couple of seconds. You still have to download the code into the box each cycle, and reboot the box and wait for all the hardware to come up, and either do all the post-boot setup (entering a bunch of data by hand) that it took to get to the state you want to debug, or else spend time writing scripts for that. I do see advantage for Forth for that scripting.
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2012-11-29 21:13 +0100 |
| Message-ID | <1dmzav7wrq19p.a0bxzh6oj5dr$.dlg@40tude.net> |
| In reply to | #17707 |
Op Thu, 29 Nov 2012 10:38:16 -0800 schreef Paul Rubin: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> it as easy to redefine basic operations like ! in VFX's native code >>> generator as it is in a typical threaded interpreter? >> Sure, you just redefine ! and load your program. > > That won't interfere with the compiler? Plus of course doing such > redefinitions requires knowing the machine language of the target box, > and I wasn't really familiar with that. Redefinitions in Forth do not interfere with existing definitions, the behavior of newer definitions is affected. If you define a word that uses the new !, it uses the new !, not the old (with the same name, it could not find the old one). Indirectly it would, if the new ! uses the old ! inside. -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-11-29 17:11 -1000 |
| Message-ID | <M_KdnfdhsNhVviXNnZ2dnUVZ_sCdnZ2d@supernews.com> |
| In reply to | #17707 |
On 11/29/12 8:38 AM, Paul Rubin wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> it as easy to redefine basic operations like ! in VFX's native code >>> generator as it is in a typical threaded interpreter? >> Sure, you just redefine ! and load your program. > > That won't interfere with the compiler? Plus of course doing such > redefinitions requires knowing the machine language of the target box, > and I wasn't really familiar with that. > >> Well, the tracing example above is pretty typical. Also, things like >> conditional breakpoints don't really have much of a place if your >> edit/compile cycle is a couple of seconds. > > You still have to download the code into the box each cycle, and reboot > the box and wait for all the hardware to come up, That adds at least a couple more seconds (at least with SwiftX). > and either do all the > post-boot setup (entering a bunch of data by hand) that it took to get > to the state you want to debug, or else spend time writing scripts for > that. I do see advantage for Forth for that scripting. Yes, SwiftForth and SwiftX let you save either the things you typed in a session (to use as debugging setup) or the complete session (to review what you did). The former is useful for reconstructing a situation under test. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-11-30 03:37 -0600 |
| Message-ID | <JqCdnZ9Gsrj94yXNnZ2dnUVZ8umdnZ2d@supernews.com> |
| In reply to | #17707 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> it as easy to redefine basic operations like ! in VFX's native code >>> generator as it is in a typical threaded interpreter? >> Sure, you just redefine ! and load your program. > > That won't interfere with the compiler? I don't quite know what you mean by "interfere", but I don't see any reason why it should. > Plus of course doing such redefinitions requires knowing the machine > language of the target box, and I wasn't really familiar with that. You don't really need it to redefine ! but I kinda assume that everyone has that knowledge when doing embedded programming. My basic assumption is a skilled professional who really knows what they are doing. >> Well, the tracing example above is pretty typical. Also, things like >> conditional breakpoints don't really have much of a place if your >> edit/compile cycle is a couple of seconds. > > You still have to download the code into the box each cycle, and > reboot the box and wait for all the hardware to come up, and either > do all the post-boot setup (entering a bunch of data by hand) that > it took to get to the state you want to debug, or else spend time > writing scripts for that. Sure, but all that should only take a couple of seconds unless you have to wait for a motor to start up or somesuch. I'll grant you that in some circumstances a bug may only appear after a while, in which case more setup is required. It's still a lot more convenient than a debugger, IME. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-30 02:11 -0800 |
| Message-ID | <7xlidje6yi.fsf@ruckus.brouhaha.com> |
| In reply to | #17755 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> Sure, you just redefine ! and load your program. >> That won't interfere with the compiler? > I don't quite know what you mean by "interfere", but I don't see any > reason why it should. I'd guess an optimizing Forth compiler might treat ! the way a C compiler treats assignment statements, and rely on it working in a specific way. >> Plus of course doing such redefinitions requires knowing the machine >> language of the target box, and I wasn't really familiar with that. > You don't really need it to redefine ! but I kinda assume that > everyone has that knowledge when doing embedded programming. Probably necessary on microcontrollers, didn't really come into play on a large-ish 68000 box that was programmed almost entirely in C. It did have some low level asm code that I ended up having to dig into a bit, but that was unexpected, and understanding it is certainly easier than writing it. Certainly nobody asked me about asm when I was hired there. > Sure, but all that should only take a couple of seconds unless you > have to wait for a motor to start up or somesuch. It was more than a few seconds but long enough ago that I don't remember just what was involved. This particular bug didn't involve a whole lot of setup. Other stuff required manually setting up a lot of connections to other equipment, physically moving boards and cables around, etc. It's possible some of the connection stuff could have been automated. That place was pretty low tech.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-11-30 05:24 -0600 |
| Message-ID | <P4qdnSey4uHKCiXNnZ2dnUVZ8qydnZ2d@supernews.com> |
| In reply to | #17757 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>> Sure, you just redefine ! and load your program. >>> That won't interfere with the compiler? >> I don't quite know what you mean by "interfere", but I don't see any >> reason why it should. > > I'd guess an optimizing Forth compiler might treat ! the way a C > compiler treats assignment statements, and rely on it working in a > specific way. In which case it's a bug: redefinition is pretty much meat 'n potatoes Forth, and it has to work. >>> Plus of course doing such redefinitions requires knowing the machine >>> language of the target box, and I wasn't really familiar with that. >> You don't really need it to redefine ! but I kinda assume that >> everyone has that knowledge when doing embedded programming. > > Probably necessary on microcontrollers, didn't really come into play > on a large-ish 68000 box that was programmed almost entirely in C. > It did have some low level asm code that I ended up having to dig > into a bit, but that was unexpected, and understanding it is > certainly easier than writing it. Certainly nobody asked me about > asm when I was hired there. Interesting. I've never been in that position. >> Sure, but all that should only take a couple of seconds unless you >> have to wait for a motor to start up or somesuch. > > It was more than a few seconds but long enough ago that I don't remember > just what was involved. This particular bug didn't involve a whole lot > of setup. Other stuff required manually setting up a lot of connections > to other equipment, physically moving boards and cables around, etc. > It's possible some of the connection stuff could have been automated. > That place was pretty low tech. This speed of loading thing is so critical to Forth development. There's a huge difference between a couple of seconds and a minute: in a minute you will start thinking about the journey home, what you're going to have for dinner, and so on. How this fast turnaround is achieved depends on the hardware: in most cases it should be possible to relaod the code being tested without restarting the machine, but on some embedded systems you can't do that. On boards with code in ROM we I have used piggybacked SRAMs in the ROM socket so that I could reload code without losing the thread of concentration. With JTAG-loaded flash it's a bit more difficult, but resetting the target shouldn't cause a long delay. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-30 11:23 -0800 |
| Message-ID | <7xobieyjwa.fsf@ruckus.brouhaha.com> |
| In reply to | #17765 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> large-ish 68000 box ... Certainly nobody asked me about >> asm when I was hired there. > Interesting. I've never been in that position. It may be more of an issue in smaller projects where one or two people are in charge of all the code and have to deal with every level. This thing had +/- a million lines of C (a lot for back then) and dozens of engineers dealing with various specific areas. When I found that bug in an asm file (by localizing the misbehavior to it, then examining the source file and spotting the error), I went over to the guy who maintained that file, and he patched it. I'd done enough asm coding on other processors that I understood what had happened, but if I were to actually mess with that code I'd have had to first spend some time with the CPU manual and then more time figuring out the part of the tool chain that had the assembler. The product also had a lot of FPGA code that I never even saw. > On boards with code in ROM we I have used piggybacked SRAMs in > the ROM socket ... With JTAG-loaded flash it's a bit more difficult, > but resetting the target shouldn't cause a long delay. This was not a board on someone's desk that could be hacked that way (maybe the hardware guys had boards they could debug like that). It was a rack full of gear costing $100K's and I only dealt with fully built units. This topic came up because hardware debuggers were mentioned and I remembered this particular incident. My manager was ok with the idea of using the company's in-circuit emulator on this bug, but it would have required getting the hardware guys involved to set it up, enough hassle that we ended up getting lucky and solving the problem without it. The generation of programmers before mine really had to do lots of extensive development in asm, and I think most the current generation mostly doesn't even know what it is, even for microcontroller stuff (the Launchpad board is supported by multiple C toolchains, for example). I had to dabble in it once in a while.
[toc] | [prev] | [next] | [standalone]
| From | the_gavino_himself <visphatesjava@gmail.com> |
|---|---|
| Date | 2012-11-29 21:16 -0800 |
| Message-ID | <ac9751e9-aafe-4ade-905b-fbf52bf8980c@googlegroups.com> |
| In reply to | #17704 |
On Thursday, November 29, 2012 10:22:43 AM UTC-8, Andrew Haley wrote: > Paul Rubin <no.email@nospam.invalid> wrote: > > > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > > >> Y'know what? It's terribly easy to add watchpoints if you have Forth. > > >> You can do it at every word, at every enter and exit, or at every > > >> store. Ten minutes, tops. > > > > > > I couldn't imagine that project using any Forth other than VFX, > > > since they were obsessed (in a bad way) with code optimization. Is > > > it as easy to redefine basic operations like ! in VFX's native code > > > generator as it is in a typical threaded interpreter? > > > > Sure, you just redefine ! and load your program. You might have to > > redefine a bunch of other words as well. Also, while you're at > > it, you might as well redefine ; . > > > > > Als, the code was full of crufty micro-optimizations in lots of > > > places where it didn't matter, but in some places it probably > > > actually did matter (some hardware in the box had real-time > > > requirements). So slowing down every store for the purpose of > > > adding software watchpoints might have messed up the box's > > > operation. > > > > Perhaps. I've been there. > > > > > For reasons I mentioned in another post though, I think programming > > > this box in Forth would have resulted in even bigger headaches than > > > the C code had. Erlang would probably have made more sense than > > > either. > > > > > >> Me too, when I don't have Forth. I use GDB for about 6 hours a day... > > > > > > I'd be interested in seeing some kind of development/debugging > > > session (maybe on video) by a good Forth programmer sometime, to see > > > what they do differently from what C programmers do. Sam Falvo has > > > some videos like that so I may try to download one and watch it. > > > > Well, the tracing example above is pretty typical. Also, things like > > conditional breakpoints don't really have much of a place if your > > edit/compile cycle is a couple of seconds. > > > > Andrew. www.cpan.org is one answer
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-11-29 08:38 -1000 |
| Message-ID | <i_adnU_5Tp4nNirNnZ2dnUVZ_rCdnZ2d@supernews.com> |
| In reply to | #17702 |
On 11/29/12 8:00 AM, Paul Rubin wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> Y'know what? It's terribly easy to add watchpoints if you have Forth. >> You can do it at every word, at every enter and exit, or at every >> store. Ten minutes, tops. SwiftForth has the ability to set watchpoints on individual cells or memory regions. > I couldn't imagine that project using any Forth other than VFX, since > they were obsessed (in a bad way) with code optimization. Is it as easy > to redefine basic operations like ! in VFX's native code generator as it > is in a typical threaded interpreter? > > Als, the code was full of crufty micro-optimizations in lots of places > where it didn't matter, but in some places it probably actually did > matter (some hardware in the box had real-time requirements). So > slowing down every store for the purpose of adding software watchpoints > might have messed up the box's operation. > > In this particular incident the box had a lot of C code and a little bit > of assembly code, and the bug (stray pointer) turned out to be in the > assembly code (it took a long while to figure this out). If the C were > Forth instead but the bug was still in assembly, then software Forth > watchpoints wouldn't have found the bug like a hardware watchpoint would > have. It might still have eliminated other possibilities more quickly > than what we did, of course. > > For reasons I mentioned in another post though, I think programming this > box in Forth would have resulted in even bigger headaches than the C > code had. Erlang would probably have made more sense than either. > >> Me too, when I don't have Forth. I use GDB for about 6 hours a day... > > I'd be interested in seeing some kind of development/debugging session > (maybe on video) by a good Forth programmer sometime, to see what they > do differently from what C programmers do. Sam Falvo has some videos > like that so I may try to download one and watch it. Yes, that would help you a lot, assuming Sam's videos are good. The fact is, Forth debugging is *nothing* like what a "good C programmer would do." It's a completely different relationship between the programmer and the code, as different as communicating via email is vs. having a face-to-face conversation. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2012-11-29 18:43 +0000 |
| Message-ID | <50b7ab7f.347456612@192.168.0.50> |
| In reply to | #17702 |
On Thu, 29 Nov 2012 10:00:56 -0800, Paul Rubin <no.email@nospam.invalid> wrote: >Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> Y'know what? It's terribly easy to add watchpoints if you have Forth. >> You can do it at every word, at every enter and exit, or at every >> store. Ten minutes, tops. > >I couldn't imagine that project using any Forth other than VFX, since >they were obsessed (in a bad way) with code optimization. Is it as easy >to redefine basic operations like ! in VFX's native code generator as it >is in a typical threaded interpreter? Of course. Try it for yourself. : <CheckThisAddr> \ addr -- ... ; : ! \ x addr -- dup <CheckThisAddr> ! ; Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2012-11-29 12:15 +0000 |
| Message-ID | <50b74de2.323490974@192.168.0.50> |
| In reply to | #17661 |
On Wed, 28 Nov 2012 23:37:43 -0800, Paul Rubin <no.email@nospam.invalid> wrote: >I remember wanting a hardware debugger to deal with a problem of >intermittent memory corruption (certain locations getting clobbered and >we couldn't figure out why) and the CPU didn't have hardware watchpoints >(that would have found the problem instantly). A software debugger with >breakpoints would have helped, but we didn't have that either, so we >ended up having to rebuild the software with tracing and reload/boot the >box dozens of times in order to close in on the problem. For embedded CPUs that support some form of crash exception and/or debugging, e.g ARM/Cortex, we provide good crash analysis tools. On the desktop VFX Forth for Windows has provided an extensive source level debugger for many years. All the VFX hosted Forths provide exception dumps that attempt to determine in which word the crash occurred. The big problem is that experienced Forth programmers don't use debuggers, so they don't get further developed. These tools are mostly training wheels for VB and C programmers. The crash dumps are invaluable, if only one can persuade people to look at them. >I've also generally found source-level single step debuggers (gdb) >invaluable even for just trying to understand code that works (as >opposed to diagnosing buggy code). If I want to figure out what some >chunk of obscure code is doing, it's far more enlightening to breakpoint >at the beginning of it and step through it with gdb, than to try to grok >its operation by pure eyeballing of the code. For reverse engineering >(though I haven't done much of that) I'm sure it's an even bigger help. > >If the embedded target supports this stuff, then great, but otherwise >it's a big slowdown not to have it. Part of the problem with Forth is that it isn't easy. It's subtle, frustrating and brutal at times. Part of the joy of Forth is that the solution to difficulty is simplicity. If the source code is too difficult to read, simplify (factor) it until you can read it. Using debuggers as a solution to bad source code is just adding flying buttresses to unsound buildings. And yes, I do have to deal with million line Forth applications. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-29 09:23 -0800 |
| Message-ID | <7xwqx4tjb9.fsf@ruckus.brouhaha.com> |
| In reply to | #17688 |
stephenXXX@mpeforth.com (Stephen Pelc) writes: >>I remember wanting a hardware debugger to deal with a problem of >>intermittent memory corruption ... > The big problem is that experienced Forth programmers don't use > debuggers... The crash dumps are invaluable, if only one can persuade > people to look at them. But this program wasn't crashing (it was losing some data but keeping on running), and even if it did crash, it would have been far too late for a crash dump to help. We knew that a certain data field was getting clobbered, at some time during the operation of this million line program. We just had no idea where or how. > Part of the problem with Forth is that it isn't easy. It's subtle, > frustrating and brutal at times. Part of the joy of Forth is that > the solution to difficulty is simplicity. If the source code is > too difficult to read, simplify (factor) it until you can read it. > Using debuggers as a solution to bad source code is just adding > flying buttresses to unsound buildings. > > And yes, I do have to deal with million line Forth applications. How long does it take you to refactor a million line Forth program that's full of cruft, and are the clients willing to pay you while you do that, if the product already works when you want to start refactoring it? It might have made sense to task you with leading a next-generation product design with all new code, but that would be a multi-year project, and the immediate requirement is to get the update for the current product out the door. Keep in mind also that the reason the code was crufty was that it was written by electrical engineers who were smart, but who didn't know anything about software and who treated programming as a foreign and somewhat evil activity required to make the hardware (that they built) do its stuff. If using Forth requires so much subtlety on the part of the programmers, that's an argument for keeping it away from a project like that. If I got to dictate the choice of languages for that product (a telecom switch), I probably would pick Erlang.
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2012-11-29 18:24 +0000 |
| Message-ID | <50b7a412.345554913@192.168.0.50> |
| In reply to | #17699 |
On Thu, 29 Nov 2012 09:23:06 -0800, Paul Rubin <no.email@nospam.invalid> wrote: >But this program wasn't crashing (it was losing some data but keeping on >running), and even if it did crash, it would have been far too late for >a crash dump to help. We knew that a certain data field was getting >clobbered, at some time during the operation of this million line >program. We just had no idea where or how. Those are difficult, especially if the hardware cannot be accessed. However, Andrew has pointed out that interactivity is a key part of the solution. Debugging requires adherence to formal scientific method. Forth scores in the speed with which you can go round the observe, hypothesis, experiment loop. I'm not arguing about the occasional validity of hardware debugging - we have drawers full of hardware assist tools. I'm arguing against too much reliance on them. >> And yes, I do have to deal with million line Forth applications. >Keep in mind also that the reason the code was crufty was that it was >written by electrical engineers who were smart, but who didn't know >anything about software and who treated programming as a foreign and >somewhat evil activity required to make the hardware (that they built) >do its stuff. All successful million line apps are old and crufty, it just goes with the territory. Engineering apps require domain experience. It is probable that only domain engineers can express what a successful application needs. Watching an application being developed by software people with no knowledge of the application domain is a truly hideous experience. Most working electrical (or construction or ...) engineers who have to write code will use a tool that they can understand. Forth is a tool that most engineers can understand. It's software people that have a problem with Forth. Regards, Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-29 11:06 -0800 |
| Message-ID | <7xsj7s44an.fsf@ruckus.brouhaha.com> |
| In reply to | #17705 |
stephenXXX@mpeforth.com (Stephen Pelc) writes: > Those are difficult, especially if the hardware cannot be accessed. > However, Andrew has pointed out that interactivity is a key part > of the solution. Debugging requires adherence to formal scientific > method. Forth scores in the speed with which you can go round the > observe, hypothesis, experiment loop. I think the interactivity would have helped, but it occurs to me that Forth is less interactive than Python in that it doesn't seem to have a standard way to interactively patch running code. If you redefine the word FOO, you have to recompile the whole program and restart it. In Python, every time you call FOO it looks up the symbol and calls it, so you can redefine on the fly. (Yes, that's one of the reasons Python is slow.) Erlang OTP has special features for hot-patching but I don't know how they work. I guess an interpreted Forth could allow redefining a word while keeping it at the old address. The new code would have to be no longer than the old code, but presumably it would just be an EXECUTE or a jump to where the rest of the patch was. Is that a standard trick? > Most working electrical (or construction or ...) engineers who > have to write code will use a tool that they can understand. > Forth is a tool that most engineers can understand. It's software > people that have a problem with Forth. This code had at least some real problems because it was written with no CS knowledge. The part I worked on was rather horrendous, a UI component that basically displayed a list of connections in increasing order of something-or-other. 1000's of lines of code tweaked and bummed into incomprehensibility because it really was using a substantial amount of CPU time and they had to keep hacking it to make it faster. The reason it was slow was that it present the items in order using a stateful selection scheme that was spread across the whole subsystem, that amounted to an ad-hoc O(n**2) sorting algorithm. Replacing that with something reasonable allowed rewriting the whole module cleanly in 1/4 of its former size and it was orders of magnitude faster too.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-11-29 17:35 -1000 |
| Message-ID | <N--dnV-k9_fptCXNnZ2dnUVZ_oydnZ2d@supernews.com> |
| In reply to | #17713 |
On 11/29/12 9:06 AM, Paul Rubin wrote: > stephenXXX@mpeforth.com (Stephen Pelc) writes: >> Those are difficult, especially if the hardware cannot be accessed. >> However, Andrew has pointed out that interactivity is a key part >> of the solution. Debugging requires adherence to formal scientific >> method. Forth scores in the speed with which you can go round the >> observe, hypothesis, experiment loop. > > I think the interactivity would have helped, but it occurs to me that > Forth is less interactive than Python in that it doesn't seem to have a > standard way to interactively patch running code. If you redefine the > word FOO, you have to recompile the whole program and restart it. In > Python, every time you call FOO it looks up the symbol and calls it, so > you can redefine on the fly. (Yes, that's one of the reasons Python is > slow.) Erlang OTP has special features for hot-patching but I don't > know how they work. > > I guess an interpreted Forth could allow redefining a word while keeping > it at the old address. The new code would have to be no longer than the > old code, but presumably it would just be an EXECUTE or a jump to where > the rest of the patch was. Is that a standard trick? It's one everybody knows, although it isn't used very often in normal Forth practice because recompiling is effectively instantaneous. It's standard practice in Open Firmware, though, because OF is shipped without source. Decompiling and patching are basics in the OF tookchest. >> Most working electrical (or construction or ...) engineers who >> have to write code will use a tool that they can understand. >> Forth is a tool that most engineers can understand. It's software >> people that have a problem with Forth. > > This code had at least some real problems because it was written with no > CS knowledge. The part I worked on was rather horrendous, a UI > component that basically displayed a list of connections in increasing > order of something-or-other. 1000's of lines of code tweaked and bummed > into incomprehensibility because it really was using a substantial > amount of CPU time and they had to keep hacking it to make it faster. > The reason it was slow was that it present the items in order using a > stateful selection scheme that was spread across the whole subsystem, > that amounted to an ad-hoc O(n**2) sorting algorithm. Replacing that > with something reasonable allowed rewriting the whole module cleanly in > 1/4 of its former size and it was orders of magnitude faster too. I remember once in the early 90's when Forth, Inc. got a call from a company that sold and maintained a product line of very expensive and complicated equipment. It had been programmed in Forth by a guy who wrote his own Forth, and then wrote this very extensive application. He died unexpectedly, leaving the code but no documentation or printed listings. They needed to make a change in an important control function. I was asked to go and see what we could do. It was a native Forth (no OS). Seated at a terminal, I was able to figure out how to print a listing in about 30 minutes. Based on that plus some dumps and decompiles, I managed to patch their program and satisfy their immediate needs in about two hours. No debuggers, no extra hardware, just Forth. This Forth was similar to Forth83, though not entirely standard. We quoted a couple of man-months to convert it to run on polyFORTH and document it, but the elected to rewrite the whole in C, which ended up taking several years. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-29 22:37 -0800 |
| Message-ID | <7xd2yvfvfr.fsf@ruckus.brouhaha.com> |
| In reply to | #17740 |
"Elizabeth D. Rather" <erather@forth.com> writes: >> I guess an interpreted Forth could allow redefining a word while keeping >> it at the old address. ... Is that a standard trick? > It's one everybody knows, although it isn't used very often in normal > Forth practice because recompiling is effectively instantaneous. Fast recompilation isn't the whole story. You're trying to debug a program that gets in trouble after spending a long time building up internal state, communicating with remote systems, has open network connections, etc. Restarting the program from zero requires re-doing all that setup independently of any recompilation. So you want to be able to patch the code without restarting the program. With python it's pretty easy to do this if you're willing to temporarily suspend the program's execution so you can poke at it, then let it resume. With Erlang you can apparently do it while the program continues to operate, I guess using Erlang's features for restarting crashed processes.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-11-29 21:08 -1000 |
| Message-ID | <kfidnahFC4P6xiXNnZ2dnUVZ_uKdnZ2d@supernews.com> |
| In reply to | #17751 |
On 11/29/12 8:37 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >>> I guess an interpreted Forth could allow redefining a word while keeping >>> it at the old address. ... Is that a standard trick? >> It's one everybody knows, although it isn't used very often in normal >> Forth practice because recompiling is effectively instantaneous. > > Fast recompilation isn't the whole story. You're trying to debug a > program that gets in trouble after spending a long time building up > internal state, communicating with remote systems, has open network > connections, etc. Restarting the program from zero requires re-doing > all that setup independently of any recompilation. So you want to be > able to patch the code without restarting the program. With python it's > pretty easy to do this if you're willing to temporarily suspend the > program's execution so you can poke at it, then let it resume. With > Erlang you can apparently do it while the program continues to operate, > I guess using Erlang's features for restarting crashed processes. > It's certainly not hard to set this up in Forth, whether ITC or compiled. The need just doesn't arise often enough to have formalized it. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web