Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #19527 > unrolled thread
| Started by | Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> |
|---|---|
| First post | 2013-02-07 22:51 +0100 |
| Last post | 2013-02-10 00:06 -0500 |
| Articles | 20 on this page of 144 — 25 participants |
Back to article view | Back to comp.lang.forth
3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-07 22:51 +0100
Re: 3D-graphics calculations using integers? "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-02-07 22:08 +0000
Re: 3D-graphics calculations using integers? AKE <assadebrahim2000@gmail.com> - 2013-02-07 14:32 -0800
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-07 23:40 +0100
Re: 3D-graphics calculations using integers? AKE <assadebrahim2000@gmail.com> - 2013-02-07 17:06 -0800
Re: 3D-graphics calculations using integers? AKE <assadebrahim2000@gmail.com> - 2013-02-07 17:07 -0800
Re: 3D-graphics calculations using integers? Pablo Hugo Reda <pabloreda@gmail.com> - 2013-02-07 14:36 -0800
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-07 23:46 +0100
Re: 3D-graphics calculations using integers? "Elizabeth D. Rather" <erather@forth.com> - 2013-02-07 16:38 -1000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 10:22 +0100
Re: 3D-graphics calculations using integers? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-08 10:26 +0000
Re: 3D-graphics calculations using integers? "Elizabeth D. Rather" <erather@forth.com> - 2013-02-07 12:50 -1000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 00:15 +0100
Re: 3D-graphics calculations using integers? kenney@cix.compulink.co.uk - 2013-02-08 14:51 -0600
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 22:02 +0100
Re: 3D-graphics calculations using integers? rickman <gnuarm@gmail.com> - 2013-02-07 18:21 -0500
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 00:30 +0100
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 00:39 +0100
Re: 3D-graphics calculations using integers? rickman <gnuarm@gmail.com> - 2013-02-07 18:51 -0500
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 12:28 +0100
Re: 3D-graphics calculations using integers? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-08 12:25 +0000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 22:04 +0100
Re: 3D-graphics calculations using integers? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-09 15:27 +0000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-09 16:36 +0100
Re: 3D-graphics calculations using integers? Mark Wills <forthfreak@gmail.com> - 2013-02-08 05:01 -0800
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 21:58 +0100
Re: 3D-graphics calculations using integers? Roberto Waltman <usenet@rwaltman.com> - 2013-02-08 10:08 -0500
Re: 3D-graphics calculations using integers? Roberto Waltman <usenet@rwaltman.com> - 2013-02-08 10:11 -0500
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 22:05 +0100
Re: 3D-graphics calculations using integers? Pablo Hugo Reda <pabloreda@gmail.com> - 2013-02-08 08:29 -0800
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 18:48 +0100
Re: 3D-graphics calculations using integers? rickman <gnuarm@gmail.com> - 2013-02-08 17:20 -0500
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 23:32 +0100
Re: 3D-graphics calculations using integers? rickman <gnuarm@gmail.com> - 2013-02-09 23:57 -0500
Re: 3D-graphics calculations using integers? "Elizabeth D. Rather" <erather@forth.com> - 2013-02-08 15:02 -1000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-09 02:24 +0100
Re: 3D-graphics calculations using integers? "Elizabeth D. Rather" <erather@forth.com> - 2013-02-08 15:58 -1000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-09 16:43 +0100
Re: 3D-graphics calculations using integers? "Elizabeth D. Rather" <erather@forth.com> - 2013-02-09 10:03 -1000
Re: 3D-graphics calculations using integers? "Ed" <invalid@nospam.com> - 2013-02-10 11:35 +1100
Re: 3D-graphics calculations using integers? humptydumpty <ouatubi@gmail.com> - 2013-02-08 23:48 -0800
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-09 16:37 +0100
OT: ANS Forth Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-09 17:27 +0100
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-09 10:06 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-09 12:26 -0800
Re: OT: ANS Forth Elizabeth D Rather <erather@forth.com> - 2013-02-09 14:38 -1000
Re: OT: ANS Forth "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-22 12:52 -0500
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-22 09:25 -1000
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-10 08:15 -0600
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-10 23:34 -0800
Re: OT: ANS Forth Josh Grams <josh@qualdan.com> - 2013-02-11 22:14 +0000
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-11 13:34 -1000
Re: OT: ANS Forth "Ed" <invalid@nospam.com> - 2013-02-11 11:52 +1100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-10 17:11 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-10 22:06 -1000
Re: OT: ANS Forth "Charles Childers" <crc@retroforth.org> - 2013-02-11 17:17 -0500
Re: OT: ANS Forth "Ed" <invalid@nospam.com> - 2013-02-13 11:42 +1100
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-12 16:07 -1000
Re: OT: ANS Forth "Ed" <invalid@nospam.com> - 2013-02-15 09:42 +1100
Re: OT: ANS Forth Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-15 00:16 +0100
Re: OT: ANS Forth "Ed" <invalid@nospam.com> - 2013-02-17 16:05 +1100
Re: OT: ANS Forth Howerd <howerdo@yahoo.co.uk> - 2013-02-17 04:16 -0800
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-17 13:12 +0000
Re: OT: ANS Forth Howerd <howerdo@yahoo.co.uk> - 2013-02-17 09:15 -0800
Re: OT: ANS Forth Brad Eckert <hwfwguy@gmail.com> - 2013-02-19 09:35 -0800
Re: OT: ANS Forth Andy Valencia <user@vsta.org> - 2013-02-19 19:25 +0000
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-19 15:35 -0600
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 00:37 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-20 23:07 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 01:38 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-21 08:50 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 15:44 -0800
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-24 03:41 +0000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 20:00 -0800
Re: OT: ANS Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-24 13:49 +0000
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-24 15:04 +0000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-24 14:52 -0800
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-24 23:51 +0000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-24 16:23 -0800
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-21 03:55 -0600
Re: OT: ANS Forth "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-22 13:01 -0500
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-22 12:26 -0600
Re: OT: ANS Forth Andy Valencia <user@vsta.org> - 2013-02-19 21:54 +0000
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-19 18:21 -0600
Re: OT: ANS Forth Brad Eckert <hwfwguy@gmail.com> - 2013-02-20 08:45 -0800
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-20 11:01 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-20 11:25 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 00:22 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-20 22:50 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 01:08 -0800
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-21 12:42 +0000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-21 13:50 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 09:36 -0800
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 01:32 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 00:50 -0800
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-24 03:03 +0100
Re: OT: ANS Forth Brad Eckert <hwfwguy@gmail.com> - 2013-02-21 09:12 -0800
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 00:38 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-21 09:01 -1000
Re: OT: ANS Forth mhx@iae.nl (Marcel Hendrix) - 2013-02-22 00:05 +0200
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-21 13:24 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 09:33 -0800
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-21 13:04 -0600
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 01:41 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 00:31 -0800
Re: OT: ANS Forth "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-02-23 09:15 +0000
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-23 04:33 -0600
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-23 13:49 +0000
Re: OT: ANS Forth Roberto Waltman <usenet@rwaltman.com> - 2013-02-23 13:35 -0500
Re: OT: ANS Forth Roberto Waltman <usenet@rwaltman.com> - 2013-02-23 13:46 -0500
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 15:26 -0800
Re: OT: ANS Forth Roberto Waltman <usenet@rwaltman.com> - 2013-02-24 09:41 -0500
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-21 09:09 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 00:37 -0800
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-23 13:57 +0000
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-23 08:47 -1000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 01:27 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 00:16 -0800
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-23 04:36 -0600
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-23 16:52 +0000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 12:39 -0800
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-25 16:27 +0000
Re: OT: ANS Forth "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-23 18:08 -0500
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-24 02:20 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-24 20:16 -0800
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-25 16:04 +0100
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-25 17:12 +0000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-25 20:44 +0100
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-25 16:45 +0100
Re: OT: ANS Forth Andy Valencia <user@vsta.org> - 2013-02-24 02:09 +0000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-24 04:03 +0100
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-25 17:58 +0000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-25 20:57 +0100
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-02 16:43 +0000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-02 18:14 +0100
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-03 13:56 +0000
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-24 03:45 -0600
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-13 04:12 -0600
Re: OT: ANS Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-13 12:24 +0000
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-11 14:41 +0000
Re: OT: ANS Forth Andy Valencia <user@vsta.org> - 2013-02-11 19:44 +0000
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-11 21:14 +0000
Re: 3D-graphics calculations using integers? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-09 18:14 -0600
Re: 3D-graphics calculations using integers? rickman <gnuarm@gmail.com> - 2013-02-10 00:06 -0500
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2013-02-22 13:01 -0500 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <kg8bn3$hk7$1@speranza.aioe.org> |
| In reply to | #19830 |
"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message news:O4ednUuOcsG7bb7MnZ2dnUVZ_qGdnZ2d@supernews.com... > Andy Valencia <user@vsta.org> wrote: > > Brad Eckert <hwfwguy@gmail.com> writes: > >> They want Forth to work the way they were taught that > >> programming languages should work. Nobody likes to > >> un-learn stuff because overriding the ego is hard. > > > > This is true of any innovative language. Having done the > > exercise multiple times, I can say as a high level > > language Forth did not compare well at all to Python, > > Prolog, OCaml, Erlang. For low level/embedded, it always > > lagged behind C. I've written a *lot* of Forth, and I > > still believe C comes out way ahead. > > Oh come on, this is bloody ridiculous. It's not ridiculous. I don't know why you keep insisting it is, except as an attempt to incite "flame wars" on C versus Forth. ( ... like 3rd time in the past year, perhaps? ...) You need to drop in on alt.os.development for a while. A third to a half of all OS developers there are using assembly for x86. The remainder are using C for OS development for x86. ARM is neglible or non-existant. All other languages are non-existant. There are pro's and con's to C versus assembly. Where's the Forth? Also, most well developed C compilers have special features and compiler options for embedded or OS work, e.g., ability to remove host dependent code, ability to not use libraries, ability to construct special pointers, pointers setable to specific addresses, ability to access memory outside the C code and data space, inline assembly, etc. Personally, I've written a very simple 32-bit x86 OS almost entirely in ANSI C. Yes, ANSI C, not ISO C. It compiles with two different C compilers. It's mostly independent of the host's C libraries. I've used a few library functions that are host OS independent, which I intend to remove at some point in the future. It's not complete yet. It's been stalled for some years now. However, none of what is left is requires anything more than me to code more C code. You may need a small amount of inline assembly for processor specific instructions, depending on the processor. C doesn't provide these. Forth doesn't either. These routines amount to one or two instructions each, e.g., for x86 instructions like LGDT, LIDT, etc. You need some modestly sized assembly routines for two situations that C doesn't handle well: interrupt wrappers and initial code startup. Just guessing, but I'd say it's 99.92% standard ANSI C. > I can understand the > argument about higher-level languages like Python, but C for > embedded work? C is crude, it has very limited > extensibiity, it has a mess of tools: compilers, linkers, > makefiles, debuggers. For embedded work, you only need the compiler. You don't need a linker, makefile, debugger, or C libraries. It's nice to have a linker also, but not required. Typically, an embedded OS is much smaller than a standalone application, and frequently has all the source code within a single file. That means an object file is all that is needed, i.e.., compiler without a linker. It's nice to have C libraries, but those aren't required either and only a small percentage of functions will be independent of the host OS anyway. > And even then it doesn't have an interactive environment. True. > The lack of extensibility [...] What lack of extensibility? You can code anything in C except special processor instructions. Those are done in inline assembly in C... > The lack of extensibility > means that whatever the language designer provides had better > better be right, because you're not going to get anything > better. And yes, I know there are IDEs that make up for some > of this, but I've never seen anything that can approach the > ease of development and interactivity of an embedded Forth > system. And, as a GCC developer, I have more than a passing > familiarity with C. > Maybe, you need "more than [just] a passing familiarity with C..." I.e., you need to understand how C _actually_ maps onto assembly and the machine architecture. Most of the truths regarding this will get you into a serious flame war or hotly argumentative discussion on comp.lang.c. In part, this is because the C specifications abstract the language from the implementation. However, if you don't accept them as truth and understand how and why they work, you'll have problems with "low-level" C work. I've mentioned them in various posts on various groups in the past. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-02-22 12:26 -0600 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <tZWdna48NK7UJbrMnZ2dnUVZ_r-dnZ2d@supernews.com> |
| In reply to | #19919 |
Rod Pemberton <do_not_have@notemailnotz.cnm> wrote: > "Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message > news:O4ednUuOcsG7bb7MnZ2dnUVZ_qGdnZ2d@supernews.com... >> Andy Valencia <user@vsta.org> wrote: >> > Brad Eckert <hwfwguy@gmail.com> writes: >> >> They want Forth to work the way they were taught that >> >> programming languages should work. Nobody likes to >> >> un-learn stuff because overriding the ego is hard. >> > >> > This is true of any innovative language. Having done the >> > exercise multiple times, I can say as a high level >> > language Forth did not compare well at all to Python, >> > Prolog, OCaml, Erlang. For low level/embedded, it always >> > lagged behind C. I've written a *lot* of Forth, and I >> > still believe C comes out way ahead. >> >> Oh come on, this is bloody ridiculous. > > It's not ridiculous. Yes, it is, and I explained why. > I don't know why you keep insisting it is, except as an attempt to > incite "flame wars" on C versus Forth. ( ... like 3rd time in the > past year, perhaps? ...) It was a reply to a posting. That posting was so far out of whack that I didn't want to let it stand. > Also, most well developed C compilers have special features and > compiler options for embedded or OS work, e.g., ability to remove > host dependent code, ability to not use libraries, ability to > construct special pointers, pointers setable to specific addresses, > ability to access memory outside the C code and data space, inline > assembly, etc. I know, I know. >> I can understand the argument about higher-level languages like >> Python, but C for embedded work? C is crude, it has very limited >> extensibiity, it has a mess of tools: compilers, linkers, >> makefiles, debuggers. > > For embedded work, you only need the compiler. You don't need a > linker, makefile, debugger, or C libraries. Don't be ridiculous. >> And even then it doesn't have an interactive environment. > > True. > >> The lack of extensibility [...] > > What lack of extensibility? You can code anything in C except > special processor instructions. Those are done in inline assembly > in C... The ability to write functions does not make a language extensible. As Wikipedia puts it: in extensible programming, a compiler is not a monolithic program that converts source code input into binary executable output. It's a set of tools that you use to create a domain-specific langauge. >> The lack of extensibility means that whatever the language designer >> provides had better better be right, because you're not going to >> get anything better. And yes, I know there are IDEs that make up >> for some of this, but I've never seen anything that can approach >> the ease of development and interactivity of an embedded Forth >> system. And, as a GCC developer, I have more than a passing >> familiarity with C. > > Maybe, you need "more than [just] a passing familiarity with C..." > I.e., you need to understand how C _actually_ maps onto assembly > and the machine architecture. Indeed you do. How else would you write a compiler? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andy Valencia <user@vsta.org> |
|---|---|
| Date | 2013-02-19 21:54 +0000 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <20130219214611.21680.52657@Nokia-N810-43-7> |
| In reply to | #19827 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > ... but C for embedded work? C > is crude, it has very limited extensibiity, it has a mess of tools: > compilers, linkers, makefiles, debuggers. And even then it doesn't > have an interactive environment. gcc, cross compilers, static analysis, gdb and slave-target gdb. And have you looked at picoc? > > Its true strength is that it provides a simple language model which > > lends itself to implementation with a modest amount of effort. And > > that this small model often provides a sweet spot when facing the > > limitations of the 16-bit world. It also provides a nostalgic > > return to simplicity in a world of massively layered software. > Well, yes it does. And this is a bad thing? Not at all. I'm a great fan of Forth for what it is. I just have gotten tired of seeing this claim that the world would adopt Forth as the One True Language if only they could suppress their reactionary stupidity. The truth is when you compare the "True Forth Dev" to the "True X Dev" (where X is C, Java, Python, ...), there are many, many scenarios where Forth is excelled. You don't seem to take exception to this statement in the higher level language space. I hope you'd at least allow that C based embedded dev is pretty darn effective--even while maintaining that Forth would be superior, pound for pound. Andy Valencia Home page: http://www.vsta.org/andy/ To contact me: http://www.vsta.org/contact/andy.html
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-02-19 18:21 -0600 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <E96dnY_8j9iDirnMnZ2dnUVZ_v-dnZ2d@supernews.com> |
| In reply to | #19831 |
Andy Valencia <user@vsta.org> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> ... but C for embedded work? C >> is crude, it has very limited extensibiity, it has a mess of tools: >> compilers, linkers, makefiles, debuggers. And even then it doesn't >> have an interactive environment. > > gcc, cross compilers, static analysis, gdb and slave-target gdb. Indeed. gdb is a tremendous piece of software, but an interactive extensible interpreter it ain't. > And have you looked at picoc? No. I've never been a huge fan of the idea. For scripting and interactive use C's syntax is too fiddly. >> > Its true strength is that it provides a simple language model which >> > lends itself to implementation with a modest amount of effort. And >> > that this small model often provides a sweet spot when facing the >> > limitations of the 16-bit world. It also provides a nostalgic >> > return to simplicity in a world of massively layered software. >> >> Well, yes it does. And this is a bad thing? > > Not at all. I'm a great fan of Forth for what it is. I just have > gotten tired of seeing this claim that the world would adopt Forth > as the One True Language if only they could suppress their > reactionary stupidity. Well, that's an idiotic thing for them to say! Any One True Language religious statement is idiotic. Is it more idiotic than saying "For low level/embedded, [Forth] always lagged behind C"? Perhaps; but not by much. > The truth is when you compare the "True Forth Dev" to the "True X > Dev" (where X is C, Java, Python, ...), there are many, many > scenarios where Forth is excelled. Sure. You can't take this in isolation from the programmers involved by simply declaring "Language X is better". It depends on the programmers. If you have a flexible and, most importantly, extensible language you can make up for an awful lot. It's a choice between a powerful but fixed language with a huge feature set and something more primitive that can be extended to fit the problem. But that requires taste and discipline. > You don't seem to take exception to this statement in the higher > level language space. I hope you'd at least allow that C based > embedded dev is pretty darn effective--even while maintaining that > Forth would be superior, pound for pound. I have no problem with that. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2013-02-20 08:45 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <51ef1ca5-e3de-42fd-acbd-289de46a90a6@googlegroups.com> |
| In reply to | #19831 |
On Tuesday, February 19, 2013 2:54:54 PM UTC-7, Andy Valencia wrote: > gcc, cross compilers, static analysis, gdb and slave-target gdb. > The last time I explained Forth to a hardware SOC designer, he asked me about breakpoints. I told him there are no breakpoints. You debug the system in situ, with the whole thing running. That threw him for a loop, because breakpoints and single stepping were all he knew. You can add instrumentation to C code, but it's not part of C and you have to do it yourself. Otherwise, you have to do the usual "kill the patient and do an autopsy" breakpoint-based debugging. The C IDEs are getting better, but C projects are still painful to watch.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-02-20 11:01 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <7xd2vux11t.fsf@ruckus.brouhaha.com> |
| In reply to | #19849 |
Brad Eckert <hwfwguy@gmail.com> writes: > The last time I explained Forth to a hardware SOC designer, he asked > me about breakpoints. I told him there are no breakpoints. You debug > the system in situ, with the whole thing running. Is that a good thing? Computers used to have front panel switches that would let you single step programs. The alternative seems to be restarting the program a lot more times, adding more and more logging til you pinpoint the problem. > You can add instrumentation to C code, but it's not part of C and you > have to do it yourself. Does that mean something different than "run the program under a debugger"? If it just means adding print statements or logging, I'd have thought Forth was the same way. > Otherwise, you have to do the usual "kill the patient and do an > autopsy" breakpoint-based debugging. I thought "kill the patient and do an autopsy" would have meant examining a core dump after the program crashed. It's always seemed easier to me to debug C programs with debuggers than with print statements. Of course that requires quite a bit of infrastructure. JTAG debuggers also exist for a reason, though I've never used one.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2013-02-20 11:25 -1000 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <i5idna3q7LLOorjMnZ2dnUVZ_v2dnZ2d@supernews.com> |
| In reply to | #19851 |
On 2/20/13 9:01 AM, Paul Rubin wrote: > Brad Eckert <hwfwguy@gmail.com> writes: >> The last time I explained Forth to a hardware SOC designer, he asked >> me about breakpoints. I told him there are no breakpoints. You debug >> the system in situ, with the whole thing running. > > Is that a good thing? Computers used to have front panel switches that > would let you single step programs. The alternative seems to be > restarting the program a lot more times, adding more and more logging > til you pinpoint the problem. Missing the point. Breakpoints are necessary to debug long sequences of code and programs that are not interactive. Forth avoids the necessity by being so extremely modular (assuming, of course, that you take advantage of this by writing your programs that way) and by being inherently interactive so you don't need external debuggers. >> You can add instrumentation to C code, but it's not part of C and you >> have to do it yourself. > > Does that mean something different than "run the program under a > debugger"? If it just means adding print statements or logging, I'd > have thought Forth was the same way. You can, of course, put prints in your Forth, but that's more of a last resort when normal debugging fails. There's a different style to debugging in Forth, just as there's a different style of programming, but the combination is incredibly powerful. Cheers, Elizabeth >> Otherwise, you have to do the usual "kill the patient and do an >> autopsy" breakpoint-based debugging. > > I thought "kill the patient and do an autopsy" would have meant > examining a core dump after the program crashed. > > It's always seemed easier to me to debug C programs with debuggers than > with print statements. Of course that requires quite a bit of > infrastructure. JTAG debuggers also exist for a reason, though I've > never used one. > -- ================================================== 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 | 2013-02-21 00:22 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <7xip5mkrew.fsf@ruckus.brouhaha.com> |
| In reply to | #19856 |
"Elizabeth D. Rather" <erather@forth.com> writes: > Missing the point. Breakpoints are necessary to debug long sequences > of code and programs that are not interactive. I don't think I understand this. Python is interactive and I find breakpoint debugging useful in it, when it's available. The alternative is far more restarts of the program during debugging. I've never used a step-backward or "time travel" debugger, but those sound useful too. They capture an instruction trace as the program executes, along with the info to undo each instruction. The way it's supposed to work is you can set a breakpoint to trigger when something is observably wrong, then step backwards to see what has happened. That sounds awesome to me. > Forth avoids the necessity by being so extremely modular (assuming, of > course, that you take advantage of this by writing your programs that > way) and by being inherently interactive so you don't need external > debuggers. I'd be interested to know how to write code like that. I don't see Forth as particularly more modular than other languages, though maybe I'm missing something, or we're not using that word the same way.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2013-02-20 22:50 -1000 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <sP-dncPLPuFUQrjMnZ2dnUVZ_oGdnZ2d@supernews.com> |
| In reply to | #19861 |
On 2/20/13 10:22 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> Missing the point. Breakpoints are necessary to debug long sequences >> of code and programs that are not interactive. > > I don't think I understand this. Python is interactive and I find > breakpoint debugging useful in it, when it's available. The alternative > is far more restarts of the program during debugging. > > I've never used a step-backward or "time travel" debugger, but those > sound useful too. They capture an instruction trace as the program > executes, along with the info to undo each instruction. The way it's > supposed to work is you can set a breakpoint to trigger when something > is observably wrong, then step backwards to see what has happened. > That sounds awesome to me. > >> Forth avoids the necessity by being so extremely modular (assuming, of >> course, that you take advantage of this by writing your programs that >> way) and by being inherently interactive so you don't need external >> debuggers. > > I'd be interested to know how to write code like that. I don't see > Forth as particularly more modular than other languages, though maybe > I'm missing something, or we're not using that word the same way. If your average word is ~3 lines or less, and you factor the contents of loops as one or a few separate words, then it's really easy to test things just by supplying appropriate arguments and typing the word, or the things that make it up if that's where the trouble is. Some Forths (including FORTH, Inc. systems) include stepping debuggers, but experienced Forth programmers that I know don't use them. They don't use them not out of any sort of philosophical rejection or pride, but simply because debugging by just typing words and watching the stack is so much simpler and easier. I have watched experienced C programmers using debuggers and breakpoints, and the whole process is just a lot more formal, slower, and more trouble than Forth-style debugging. A lot of Forths automatically display the stack, which facilitates this style. And FORTH, Inc. systems record your command window, so you can "replay" test sequences if you want to. 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 | 2013-02-21 01:08 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <7xzjyyrq3v.fsf@ruckus.brouhaha.com> |
| In reply to | #19863 |
"Elizabeth D. Rather" <erather@forth.com> writes: > If your average word is ~3 lines or less, and you factor the contents > of loops as one or a few separate words, then it's really easy to test > things just by supplying appropriate arguments and typing the word, or > the things that make it up if that's where the trouble is. Testing individual words isn't of much help when the problem you're debugging is with how some bigger subsystems interact, or with some weird edge case that you're testing missed, or some word getting unexpected input that it wasn't written to handle, etc. Soemwhere in there, it's a safe bet, actual debugging is still going to be needed from time to time. > A lot of Forths automatically display the stack, which facilitates > this style. And FORTH, Inc. systems record your command window, so you > can "replay" test sequences if you want to. What good is automatically displaying the stack if it's changing millions of times per second? You have to be able to stop execution of the program to look at the stack. Breakpoints help with that. Also, are those tethered Forths that you're describing, that display the stack and record the command window? Or do resident Forths also do that?
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2013-02-21 12:42 +0000 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <51261622$0$26869$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #19865 |
In article <7xzjyyrq3v.fsf@ruckus.brouhaha.com>, Paul Rubin <no.email@nospam.invalid> wrote: >"Elizabeth D. Rather" <erather@forth.com> writes: >> If your average word is ~3 lines or less, and you factor the contents >> of loops as one or a few separate words, then it's really easy to test >> things just by supplying appropriate arguments and typing the word, or >> the things that make it up if that's where the trouble is. > >Testing individual words isn't of much help when the problem you're >debugging is with how some bigger subsystems interact, or with some >weird edge case that you're testing missed, or some word getting >unexpected input that it wasn't written to handle, etc. Soemwhere in >there, it's a safe bet, actual debugging is still going to be needed >from time to time. In my 40 years of experience, whenever you need this type of "actual debugging" you're in deep trouble. If I need my own programs running, a Forth style build up of the program is better. You describe a situation where the division into subsystem is faulty, such that you can't isolate the problem. Or a division is inherently problematic such as with interrupts. I remember a situation where the program failed because fp register needed to be saved in an interrupt. My week debugging would have been better spend in reading documentation. > >> A lot of Forths automatically display the stack, which facilitates >> this style. And FORTH, Inc. systems record your command window, so you >> can "replay" test sequences if you want to. > >What good is automatically displaying the stack if it's changing >millions of times per second? You have to be able to stop execution of >the program to look at the stack. Breakpoints help with that. > >Also, are those tethered Forths that you're describing, that display the >stack and record the command window? Or do resident Forths also do >that? Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-02-21 13:50 +0100 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <kg5570$c8e$1@online.de> |
| In reply to | #19865 |
Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> If your average word is ~3 lines or less, and you factor the contents >> of loops as one or a few separate words, then it's really easy to test >> things just by supplying appropriate arguments and typing the word, or >> the things that make it up if that's where the trouble is. > > Testing individual words isn't of much help when the problem you're > debugging is with how some bigger subsystems interact, or with some > weird edge case that you're testing missed, or some word getting > unexpected input that it wasn't written to handle, etc. Soemwhere in > there, it's a safe bet, actual debugging is still going to be needed > from time to time. A lot of debugging I've done through the last year was the flow control algorithm of net2o. Well, it didn't crash on wrong inputs, that's not the problem of a faulty flow control algorithm. It filled buffers and dropped packets, which it shouldn't do. And it only did so when there were more than one connections active in parallel, because that's the hard part - the single connection was easy and worked right out of the box. So how would you debug this with breakpoints and single steps? If you stop the program, the flow control won't be necessary. If you stop it for too long, the other side will give up with a timeout error - it's a networked program, sender and receiver are on different computers. The only way to get it right is to instrument the program, and trace all important informations. What to trace depends on which functionality you want to check. I even started to send the trace records around as part of the net2o protocol. The extensibility of Forth includes the debugging. You have to solve a task? You write a domain specific language. You have to debug this? You write domain-specific debugging features. If you develop a network protocol, you need a protocol analyzer. It will be written as part of the entire effort. These tools are often pretty small. E.g. take a look here: https://fossil.net2o.de/net2o/artifact/16124d717233f7079e4f28b93d6c52ae233c7667 This debugging facility has now partly included into Gforth, and I'm probably moving more into Gforth (also the profiling stuff). You can instrument your code with debugging outputs, embraced in <name>( ), and turn these named debugging chunks on and off as you like (at run-time). >> A lot of Forths automatically display the stack, which facilitates >> this style. And FORTH, Inc. systems record your command window, so you >> can "replay" test sequences if you want to. > > What good is automatically displaying the stack if it's changing > millions of times per second? You have to be able to stop execution of > the program to look at the stack. Breakpoints help with that. No, you just have to be able to look back at your trace dump. Stop the program? Doesn't work if it is a real time program, it can't be stopped. > Also, are those tethered Forths that you're describing, that display the > stack and record the command window? Or do resident Forths also do > that? For embedded systems, usually the terminal does the command window recording. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-02-21 09:36 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <7x621l4lht.fsf@ruckus.brouhaha.com> |
| In reply to | #19874 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > These tools are often pretty small. E.g. take a look here: > https://fossil.net2o.de/net2o/artifact/16124d717233f7079e4f28b93d6c52ae233c7667 This looks interesting. I'll look at it some more later. Thanks.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-02-22 01:32 +0100 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <kg6ebs$91u$2@online.de> |
| In reply to | #19882 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> These tools are often pretty small. E.g. take a look here: >> https://fossil.net2o.de/net2o/artifact/16124d717233f7079e4f28b93d6c52ae233c7667 > > This looks interesting. I'll look at it some more later. Thanks. Part of the code is now in Gforth's assert.fs http://git.savannah.gnu.org/cgit/gforth.git/tree/assert.fs -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-02-23 00:50 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <7xk3pzpg68.fsf@ruckus.brouhaha.com> |
| In reply to | #19874 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > So how would you debug this with breakpoints and single steps? If you > stop the program, the flow control won't be necessary. If you stop it > for too long, the other side will give up with a timeout error - it's > a networked program, sender and receiver are on different computers. The traditional OOP way is with dependency injection. You're probably familiar with it. Basically you encapsulate the entire interface to the outside world in an object, so that all operations such as sending network data are operations on the object, while events such as timeouts or received packets are presented by the object as a linear event stream, maybe multiplexing stuff from multiple threads. Then your flow control algorithm becomes a single threaded event loop. Next you write another object (the "mock object") with the same interface as the "outside world" object, so the flow control code doesn't care which of these objects it's talking to, but that supplies fake inputs instead of actually talking to real devices. Finally, instrument the "outside world" object to log all the events going out, so you have a captured trace when packets are lost. Use the mock object to play this trace back into the flow control algorithm. Now you can use a single-step debugger (or some other method) to see where the flow control algorithm is going wrong. Python has some quite nice libraries for the above approach and it works really well. > For embedded systems, usually the terminal does the command window > recording. That sounds reasonable. Running the terminal under emacs probably makes cutting and pasting easier.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-02-24 03:03 +0100 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <kgbse2$m1a$1@online.de> |
| In reply to | #19938 |
Paul Rubin wrote: > Finally, instrument the "outside world" object to log all the events > going out, so you have a captured trace when packets are lost. Use the > mock object to play this trace back into the flow control algorithm. > Now you can use a single-step debugger (or some other method) to see > where the flow control algorithm is going wrong. Actually, I just do the tracing inside, and do the outside world with standard reality, no simulator needed. Do you know how your wireless rounter reacts on congestions, how its buffers fill up, and how often a random packet gets dropped? I don't, or let's say: I didn't. Writing a simulator instead of using reality is often a waste of time. But only so, if you actually record and keep what you measured from reality. As Andrew Haley said, reality is usually so complex that you don't want to write an accurate simulator. And you have to understand reality and optimize for real conditions, instead for simulated ones. TCP behaves rather nice on network simulators. It behaves rather worse in reality, and the people who designed TCP show their lack of understanding by naming the TCP problems "buffer bloat" and such, indicating that they are looking for someone else to take the blame. net2o wants to fix the real problems, not the simulated ones. Buffers are good, and packet drops in WLANs are unavoidable, and just one problem. Speed changes due to signal strength changes happen very frequently. Just for comparison: When I started the flow control debugging, I simply had the programs running on two machines (connected by WLAN and DSL lines), collecting informations on both sides - that's the typical setup most internet users have today. The test data was ~10 megabytes large (the 3 seconds with 3MB/s over WLAN), the collected information below 100k. And I used scp to get the data back to my local machine, for analysis. The scp did usually take longer than the net2o test run. Both net2o and scp do roughtly the same thing: Transfer files with an encrpyted and authenticated protocol, using a key exchange at the beginning and symmetric encryption for the rest, with a flow control that aims to use the achievable bandwidth. The difference is that net2o establishes the encrypted connection in a standard handshake together with everything else (including asking for the files to transfer), and needs just one further RTD to get up to full speed. And then it doesn't let itself disturb by random garbled WLAN packets. You don't get there without looking at reality. This is a very Forth-ish approach at programming: You have to understand the problem to solve it, so your way to solution not only involves solving the problem itself, but also to analyze the problem, for a better understanding of its nature. To be honest: I significantly underestimated the effort of the flow control. When I started, I thought algorithms like LEDBAT did solve the problems. And then I tried them and they don't. Back to the drawing board. And then, I figured out that to achieve fairness with a dead simple algorithm, you'd need a really simple change in the buffer handling of the router - but the router is off limits for the first deployment of net2o, it absolutely must work with today's routers, and offer as many advantages as possible. So, with the random buffer policy of today's routers and switches, this was really tricky. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2013-02-21 09:12 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <8c0602e0-ca23-47e0-98e4-b2f1df1d55c9@googlegroups.com> |
| In reply to | #19865 |
On Thursday, February 21, 2013 2:08:36 AM UTC-7, Paul Rubin wrote: > What good is automatically displaying the stack if it's changing > millions of times per second? You have to be able to stop execution of > the program to look at the stack. Breakpoints help with that. > The stack in the debugger task isn't changing when you look at it. In effect, that thread is stopped. You don't want to stop all threads in a realtime system. That's like landing the observation plane and setting out on foot.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-02-23 00:38 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <7x621jpgq9.fsf@ruckus.brouhaha.com> |
| In reply to | #19880 |
Brad Eckert <hwfwguy@gmail.com> writes: > The stack in the debugger task isn't changing when you look at it. In > effect, that thread is stopped. You don't want to stop all threads in > a realtime system. This is cool, if you can leave the other threads running while inspecting stuff with an interactive thread. Erlang has something like that, but it relies on Erlang's rather serious process isolation.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2013-02-21 09:01 -1000 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <ooOdnQcktt-88rvMnZ2dnUVZ_vadnZ2d@supernews.com> |
| In reply to | #19865 |
On 2/20/13 11:08 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> If your average word is ~3 lines or less, and you factor the contents >> of loops as one or a few separate words, then it's really easy to test >> things just by supplying appropriate arguments and typing the word, or >> the things that make it up if that's where the trouble is. > > Testing individual words isn't of much help when the problem you're > debugging is with how some bigger subsystems interact, or with some > weird edge case that you're testing missed, or some word getting > unexpected input that it wasn't written to handle, etc. Soemwhere in > there, it's a safe bet, actual debugging is still going to be needed > from time to time. Ah, but in a complex application the "bigger subsystems" are also individual words a few lines long, as are their components. So, when you get the whole thing together and there's some problem with the interaction, you can work with the components of the subsystems causing the trouble at whatever level is productive. >> A lot of Forths automatically display the stack, which facilitates >> this style. And FORTH, Inc. systems record your command window, so you >> can "replay" test sequences if you want to. > > What good is automatically displaying the stack if it's changing > millions of times per second? You have to be able to stop execution of > the program to look at the stack. Breakpoints help with that. No, not during execution, but in testing. You start at the beginning of the section you're trying to debug, enter some parameters and type the first word you're testing. You can look at the stack display, and see if it's what you expect. Then type the next word (without having to set up the parameters again, since they're still there). So, fairly quickly you work your way through this section of code, and likely you'll see that either there's the wrong number of things on the stack, or one doesn't look right, or a word will abort (thus "outing" itself as the culpret), etc. Since you're working at the 'word' level (which can be fairly considerable blocks of code, depending on what part of the application you're testing) this is a lot faster in terms of your time than working via breakpoints and instruction-level stepping. > Also, are those tethered Forths that you're describing, that display the > stack and record the command window? Or do resident Forths also do > that? Cross-compilers can replicate resident system testing with very minor differences. 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 | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2013-02-22 00:05 +0200 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <88980313018434@frunobulax.edu> |
| In reply to | #19865 |
Paul Rubin <no.email@nospam.invalid> writes Re: OT: ANS Forth [..] > Testing individual words isn't of much help when the problem you're > debugging is with how some bigger subsystems interact, or with some > weird edge case that you're testing missed, or some word getting > unexpected input that it wasn't written to handle, etc. Soemwhere in > there, it's a safe bet, actual debugging is still going to be needed > from time to time. When I have a problem in a DLL that my Forth calls, I set a breakpoint in the ( C ) dll and attach to iForth. I then interactively work with Forth until the breakpoint triggers. In the C debugger I can see registers and parameters or do single stepping. At any point I can go back to the Forth interpreter (continue, iForth catches the excpetion if there is one) and setup a scripts/words that trigger the breakpoint with narrowed conditions or changed parameters. On the Forth commandline I have complete control over memory with DUMP, @, ! etc., (I never can remember the debugger commands). I find the combination extremely powerful. -marcel
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web