Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #19527 > unrolled thread

3D-graphics calculations using integers?

Back to article view | Back to comp.lang.forth

Contents

  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 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8  Next page →

#19959 — Re: OT: ANS Forth

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Somehow compilation never really gets faster.  In the early 90s
> building Gforth took a few minutes, and now, 20 years later, it still
> does.  Is Gforth huge?  Not compared to most other programs.

I just downloaded gforth 0.7.1 from your web site, unpacked the tarball,
ran ./configure, and typed "make -j5" on a Core i3-2130 box (2 physical
cores, 4 hardware threads, 3.4 Ghz, 8GB ram, conventional hard disks
with software RAID-1, 64-bit Debian 6, gcc 4.4.5).  The "make" took
about 7 elapsed seconds (15 cpu seconds) on the first try.  Running
"make clean" and then compiling again (make -j5) took about 5 elapsed
seconds.  I'd expect this to be in the under 3 second range on a more
recent 4-core or 6-core i7, but I don't have one of those where I am
right now.

> Ok, if you change some piece of C code, you don't spend the same time
> as when building from scratch, but it's still often not that much
> less.

I touched the largest C file (engine/main.c) and ran make -j5 again.
That took a little over 2 seconds, though it did bunch of other stuff
(e.g. ran some diagnostics) besides just recompiling the changed file
and linking a new executable.

> Anyway, even for programs that compile very fast, the C way takes more
> steps and is therefore less convenient.

You mean running "make"?

>>Some advice if you haven't done this yet: buy an SSD for your computer.
> Maybe if you have an OS that does not know how to cache files in RAM.

Really, it makes a huge difference as stuff does get dropped from
cache after a while.

>>> The tool I'm using for that is usually Gforth's ~~, it just prints
>>> out what's on the stack, and where in the sourcecode this print is
>>> located.

I've used this and it's helpful, but I kept thinking it would be
easier to single step and see what was happening.  I usually have
to edit and re-run multiple times to get the ~~ into the right
place for the output to be useful.

>>With gdb I'd just say "watch <variable>" and gdb stops the program when
>>the variable changes.
>
> And then I have to search for the next change of that variable, and
> the next, until I find the one that's wrong.  A big waste of time if
> the decisive change is after 1000 changes.

You can script gdb in python now (I haven't tried that yet) so 
you can probably get it to restart after the watchpoint until 
it sees a problem.

>>It either sets a hardware watchpoint (if one is
>>available), or single steps the program until it sees the change.
>
> And dog-slow if single-stepping is needed.  Not really a good idea for
> your program that takes 5 minutes to reach the interesting place when
> running at full speed.

True.  You might be able to use a conditional breakpoint to stop the
program a shorter distance before the interesting place.  Then start the
program at full speed, and set the watchpoint after the breakpoint is
hit.

I've only used that single-step watchpoint a couple of times and yes it
was very slow, but it saved a lot of manual effort that would have taken
even longer.  With a hardware watchpoint, it's almost painless.

[toc] | [prev] | [next] | [standalone]

#20017 — Re: OT: ANS Forth

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Somehow compilation never really gets faster.  In the early 90s
>> building Gforth took a few minutes, and now, 20 years later, it still
>> does.  Is Gforth huge?  Not compared to most other programs.
>
>I just downloaded gforth 0.7.1 from your web site, unpacked the tarball,
>ran ./configure, and typed "make -j5" on a Core i3-2130 box (2 physical
>cores, 4 hardware threads, 3.4 Ghz, 8GB ram, conventional hard disks
>with software RAID-1, 64-bit Debian 6, gcc 4.4.5).  The "make" took
>about 7 elapsed seconds (15 cpu seconds) on the first try.

You convenientkly forgot to time the ./configure, but ok, that's not
that often necessary when changin C code.

>> Ok, if you change some piece of C code, you don't spend the same time
>> as when building from scratch, but it's still often not that much
>> less.
>
>I touched the largest C file (engine/main.c) and ran make -j5 again.
>That took a little over 2 seconds, though it did bunch of other stuff
>(e.g. ran some diagnostics) besides just recompiling the changed file
>and linking a new executable.

Better touch engine/forth.h.

>> Anyway, even for programs that compile very fast, the C way takes more
>> steps and is therefore less convenient.
>
>You mean running "make"?

Yes.

>>>> The tool I'm using for that is usually Gforth's ~~, it just prints
>>>> out what's on the stack, and where in the sourcecode this print is
>>>> located.
>
>I've used this and it's helpful, but I kept thinking it would be
>easier to single step and see what was happening.  I usually have
>to edit and re-run multiple times to get the ~~ into the right
>place for the output to be useful.

Me too.  It's still much faster than stepping through the program in
the hope of that the next step will show up the problem.

>>>With gdb I'd just say "watch <variable>" and gdb stops the program when
>>>the variable changes.
>>
>> And then I have to search for the next change of that variable, and
>> the next, until I find the one that's wrong.  A big waste of time if
>> the decisive change is after 1000 changes.
>
>You can script gdb in python now (I haven't tried that yet) so 
>you can probably get it to restart after the watchpoint until 
>it sees a problem.

If I know how to check for the problem automatically, I write an
assertion (in both Forth and C).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#19965 — Re: OT: ANS Forth

"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
news:2013Feb23.175250@mips.complang.tuwien.ac.at...

> People don't use printf debugging in C because they don't
> know gdb, but because they know it.

I use printf() debugging (or the equivalent for non-C languages)
because:

1) It's generally quick and easy.

2) The ability to print is always available, unlike debuggers.

3) It's capable of displaying any standard data type in a readable
format.

4) I can target what I what to see immediately.

5) It only takes a simple edit and recompile to look at something
else, or to look at more things together.

6) It can output large amounts of data, especially in loops, which
can help identify the problem quickly.

7) I don't need to learn numerous debugger commands, which change
from debugger to debugger.

8) I don't need to step through thousands of instructions just to
get to the location of the problem.

9) I can redirect the output to a file if it's too much to view at
once.

10) printf() allocates memory for many C compilers.  If the
problem goes away after using printf(), then there is a missing or
incorrect memory allocation somewhere in the program.

11) There is no debugger modifying the execution instance.  This
can create false problems.

etc.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#19975 — Re: OT: ANS Forth

Paul Rubin wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> Yeah, you can always put up a straw man.  Reality is that the
>> recompilation time of a C program is 5 minutes,
> 
> The 1980's called and they want their VAX back ;-).  Today's computers
> are a lot faster and compiling is quick unless the program is huge.

The VAXes took hours.

> Some advice if you haven't done this yet: buy an SSD for your computer.
> It changes the whole computing experience drastically and for the
> better.

For starting bloatware, yes, but for compiling, just get more RAM.  All the 
stuff of your project is in memory.  You have gigabytes of cache RAM on any 
decent machines.  When I compile, the HD led does the occasional blink, 
which means it is writing the changed stuff back in the background.  
Comparison: The non-SSD netbook takes 55s to compile Gforth fully (touch 
configure.in; make) when nothing is in the cache, and 49s when everything is 
cached.  And Gforth is a relatively small C program, the majority of the 
source code is Forth.  And that compiles in the blink of an eye.

>> and the bug shows up almost instantly.
> 
> Welcome to the world of intermittent bugs, or bugs that are triggered by
> the program interacting with slow external systems that you don't control.

Well, I said I *do* have those, too.  But they are not the majority of the 
cases.

>> Yeah, you should automate your test cases that trigger the bug, too.
> 
> That's real nice, except it means you have to simulate the weird
> external systems, including their undocumented bugs that are causing
> your own program to fail.

No, you must do worse things.  You must deliberately try to break your 
program.  Well, very few programmers master that art, so you think you only 
need to test your program for the existing bugs in the external systems?  
You have to test them for the not-yet-existing bugs, and the deliberate 
malicious attacks, too!

People who just send garbage to existing systems find tons of bugs in 
minutes.  Because the systems have never been tested with a garbage in 
generator.  But that's a dead easy test to write!

> In reality there's not time in the project
> schedule for that even if you can figure out how to make the simulation
> accurate enough.  You instead have to keep running actual tests that
> involve pressing a lot of buttons on the external device, and those are
> time-consuming.

It helps a lot if you record all these unavoidable slow external stuff, and 
spend the time to allow it to be fed back into your program at high speed.  
Running regression tests is a good idea in any case.

Just an example:  When I did the battery monitor thing, we had to run 
charge/discharge cycles to characterize our batteries, as well as to test if 
the software behaves as it should.  The data was all recorded, and it was 
possible to rerun data through the monitor software in an instant - the 
actual battery cycle took hours to days (depending on the actual load).  You 
need this reality, *and* you need to automate this.

It was a task next to impossible to explain to my manager at Dialog why I 
did need this precise recording of the raw data.  We did waste a week or so, 
because one of my coworker followed the advice of his boss, and threw away 
that raw data.  We had to repeat the tests.  BTW: all tests were fully 
automated and scripted, so it wasn't human labor, it was just to wait for 
the batteries to charge and discharge.

It does pay off a lot if you simply ignore the stupidity of higher 
management, and spend the time to automate everything.  And in Forth, it 
usually is quite simple to do, as your application will have a natural way 
to be scripted.  Just add a way to record the inputs as script.

As the task was a monitor system, this was a lot easier than if it was a 
controlling system, as the monitor only observes, but doesn't actually 
influence things.  That one made it easier.

However, I also did write controlling software, the last one was the Triceps 
2 demo (a pick&place robot playing peg solitaire).  It took about a week to 
program, and one game to play takes ~10 minutes.  You can trust me that I 
did only run about 4 or 5 of those 10 minutes runs in the entire 
development.  And then, we went to the LinuxTag exhibition, and had it run 
for 5 days, 12 hours each, nonstop, without a single software problem.

> Sometimes they also use up consumable materials that
> could in principle be expensive, so that by itself is a reason to not
> want to run the tests too many times.

Indeed.  That's one of the driving forces behind recording everything.

>> The tool I'm using for that is usually Gforth's ~~, it just prints out
>> what's on the stack, and where in the sourcecode this print is located.
> 
> You might have to run that ~~ millions of times before the variable
> is set to the wrong value.  Do you do something to locate the change
> afterwards?

Yes, add an assertion.  It will make it easy to find that spot, either by 
throwing an exception and stopping the program (when that is something you 
can afford), or by printing diagnostics, adjusting the wrongly set variable 
to something in range, so that the program can continue without causing 
bigger harm.  Programs can be pretty fault tolerant.

> With gdb I'd just say "watch <variable>" and gdb stops the program when
> the variable changes.  It either sets a hardware watchpoint (if one is
> available), or single steps the program until it sees the change.

Yes, I know.  I don't *want* it to stop.  I just want it to print the result 
and continue.  I might have to wait for a million changes of the variable to 
find the one which is wrong.  AFAIK you can do this in gdb by adding a gdb 
script to the watchpoint, but it is rather tedious, especially, as you also 
want to print other informations, too.  Inserting ~~ at the places you want 
to observe is much easier.

BTW: It's a good idea to learn Verilog and the tools you use to debug this, 
because they follow the trace principle, too.  Verilog programs are highly 
parallel, and single stepping is absolutely useless (all the expensive tools 
provide single stepping, nonetheless.  The cheap ones don't.  The original 
b16 was developed with Icarus Verilog and GTK wave - this is a good set of 
cheap tools, which provide only those things you need).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#20003 — Re: OT: ANS Forth

Bernd Paysan <bernd.paysan@gmx.de> writes:
>> That's real nice, except it means you have to simulate the weird
>> external systems, including their undocumented bugs that are causing
>> your own program to fail.
> No, you must do worse things.  You must deliberately try to break your 
> program. 

True of course. But your program is failing if the end user sees
misbehaviour from what they expected to see, even if the misbehaviour is
actually caused by the external system not acting the way you expected.
And it may take a lot of tests to characterize the external system
enough for your system's reliability requirements.  For critical
systems, "a lot" may actually mean "infinite" and you simply can't
develop that way, you need a level of control over the external system
that you can't get from testing.

In the case of your battery charger thing, you mention you ran some
automated tests for several weeks--but the characteristics of batteries
change as they age, over a period of years, and a charging system
(especially with internal batteries like Apple uses) has to take that
into account.  Maybe batteries are well enough understood by now that
there were some parameters you could plug into your model for that.  If
the battery were instead some weird device running crazy legacy software
that you couldn't access, well, there's an awful lot of potential
complexity.

> Because the systems have never been tested with a garbage in 
> generator.  But that's a dead easy test to write!

Indeed.  In Haskell there's a library that does it for you
automatically, generating random test data that fits the inferred
type signatures of the functions under test:

http://www.cse.chalmers.se/~rjmh/QuickCheck/

> It helps a lot if you record all these unavoidable slow external
> stuff, and spend the time to allow it to be fed back into your program
> at high speed.

Yes, I think we are talking about the same thing ("dependency injection"
is the OOP term).  Python has libraries that I mentioned for the
purpose, but of course you can also write custom code that does similar
things.

> It does pay off a lot if you simply ignore the stupidity of higher
> management, and spend the time to automate everything.

Yeah, there's not a one-size-fits-all solution, but even if you can only
automate the easy cases, that saves a lot of work.

> And in Forth, it usually is quite simple to do, as your application
> will have a natural way to be scripted.  

It seems to me that this really has to be cooked into the program
structure from the beginning, which takes some foresight and vigilance,
thus the "test-driven development" concept of writing the tests first
and the code afterwards (to make sure the code is testable that way).
If you've already developed a habit of writing code in a style where
that happens naturally, that's great.

> AFAIK you can do this in gdb by adding a gdb script to the watchpoint,
> but it is rather tedious... Inserting ~~ at the places you want to
> observe is much easier.

The idea of watchpoints is that you don't know where the value is
getting clobbered, so you have to observe basically everywhere.  Andrew
Haley points out that in Forth you can get a similar effect by
redefining "!" to trap updates to specific locations, so that
can replace watchpoints to an extent.

> BTW: It's a good idea to learn Verilog and the tools you use to debug
> this, because they follow the trace principle, too... The original
> b16 was developed with Icarus Verilog and GTK wave - this is a good
> set of cheap tools, which provide only those things you need).

I'd like to try coding something in Verilog someday (too busy right
now).  I've looked at some bits of Verilog code and I think I understand
it.  I'd prefer to stay with pure FOSS implementations but those are
hard to come by.  I might buy one of these boards or something similar,
and just run the stuff that comes with it:

  http://adafruit.com/category/products/451

I'd be happy to know your thoughts on this.

[toc] | [prev] | [next] | [standalone]

#20013 — Re: OT: ANS Forth

Paul Rubin wrote:
> I'd like to try coding something in Verilog someday (too busy right
> now).  I've looked at some bits of Verilog code and I think I understand
> it.  I'd prefer to stay with pure FOSS implementations but those are
> hard to come by.  I might buy one of these boards or something similar,
> and just run the stuff that comes with it:
> 
>   http://adafruit.com/category/products/451
> 
> I'd be happy to know your thoughts on this.

The DE series with Altera Cyclones is an excellent starting point for FPGA 
development (choose whichever x fits for your purpose).  Note that Altera 
themselves quote $79 for the DE0-Nano, so maybe you'll find a cheaper 
distributor.

The seven-segment 4-digit LED display on the normal DE0 and DE1 is a good 
tool for hands-on debugging (can display 16 bit numbers in hex), so I would 
suggest to take the DE0 without nano, though it has an older device in it 
and costs a bit more.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#20019 — Re: OT: ANS Forth

In article <kgfuik$693$1@online.de>, Bernd Paysan  <bernd.paysan@gmx.de> wrote:
>Paul Rubin wrote:
>> I'd like to try coding something in Verilog someday (too busy right
>> now).  I've looked at some bits of Verilog code and I think I understand
>> it.  I'd prefer to stay with pure FOSS implementations but those are
>> hard to come by.  I might buy one of these boards or something similar,
>> and just run the stuff that comes with it:
>>
>>   http://adafruit.com/category/products/451
>>
>> I'd be happy to know your thoughts on this.
>
>The DE series with Altera Cyclones is an excellent starting point for FPGA
>development (choose whichever x fits for your purpose).  Note that Altera
>themselves quote $79 for the DE0-Nano, so maybe you'll find a cheaper
>distributor.

What are your thoughts on the EURO 60 developer board of Elektor?
Would it support a Forth processor?

>
>--
>Bernd Paysan

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#20027 — Re: OT: ANS Forth

Albert van der Horst wrote:
> What are your thoughts on the EURO 60 developer board of Elektor?

It's a bit too crammed together.  If you are space-constrained to a DIP-40 
socket, go for it.

> Would it support a Forth processor?

Yes, sure.

For a beginner, who will use the "free beer" software from the FPGA maker, 
the least frustrating development software IMHO is that from Altera, but 
Xilinx is not really much worse.  I've tried Xilinx, Altera, and LSI Logic, 
and IMHO, the market share corresponds to software quality; the hardware 
capability is similar.  Actel is a bit a special case, they have a different 
technology, but use Synplify as design software, which is the best choice 
(for all the others, Synplify is pretty expensive; if you do professional 
development, it is worth the price).  However, even though Actel's FPGAs are 
smaller than the competitors, they are large enough for a Forth CPU.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#20014 — Re: OT: ANS Forth

Paul Rubin wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
> In the case of your battery charger thing, you mention you ran some
> automated tests for several weeks--but the characteristics of batteries
> change as they age, over a period of years, and a charging system
> (especially with internal batteries like Apple uses) has to take that
> into account.

We got deliberately aged batteries from Apple.  Yes, you have to do that.

> Maybe batteries are well enough understood by now that
> there were some parameters you could plug into your model for that.

No, neither we nor Apple or their battery manufacturers did really know how 
the old batteries change (apart from the reduced capacity), so we did the 
same automated tests on the old batteries to find out.

> If
> the battery were instead some weird device running crazy legacy software
> that you couldn't access, well, there's an awful lot of potential
> complexity.

Sure.

>> Because the systems have never been tested with a garbage in
>> generator.  But that's a dead easy test to write!
> 
> Indeed.  In Haskell there's a library that does it for you
> automatically, generating random test data that fits the inferred
> type signatures of the functions under test:
> 
> http://www.cse.chalmers.se/~rjmh/QuickCheck/

Especially easy with the Haskell style where many functions are side-effect-
free.

>> And in Forth, it usually is quite simple to do, as your application
>> will have a natural way to be scripted.
> 
> It seems to me that this really has to be cooked into the program
> structure from the beginning, which takes some foresight and vigilance,
> thus the "test-driven development" concept of writing the tests first
> and the code afterwards (to make sure the code is testable that way).
> If you've already developed a habit of writing code in a style where
> that happens naturally, that's great.

This is not so much done that way in Forth; people code and test things 
together.  Write one word at a time, and test it as you go.

>> AFAIK you can do this in gdb by adding a gdb script to the watchpoint,
>> but it is rather tedious... Inserting ~~ at the places you want to
>> observe is much easier.
> 
> The idea of watchpoints is that you don't know where the value is
> getting clobbered, so you have to observe basically everywhere.  Andrew
> Haley points out that in Forth you can get a similar effect by
> redefining "!" to trap updates to specific locations, so that
> can replace watchpoints to an extent.

You can also change the code of the variable itself.  Example, maybe this is 
a good thing to add to Gforth's debugging stuff:

: watch-does> ( -- ) DOES> dup @ ~~ drop ;
: watch-compile> ( -- ) COMPILE> >body ]] Literal dup @ ~~ drop [[ ; 
: watched ( "name" -- )
  Create 0 , watch-does> watch-compile> ;

This shows the variable's address and its value whenever the variable is 
used, and prints source code location and stack.  This might need a bit of 
further polishing (printing the variable's name would be nice).  And you 
might want to turn this watching on and off.  Both is not difficult.  You 
still don't see which ! does the change (could as well be a +!, an ON or OFF 
or a MOVE - there are several memory-changing operations).

It might be beneficial to use values for watching changes, as there, you 
have only to instrument TO.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#19977 — Re: OT: ANS Forth

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> For goodness' sake, this is Forth!  Just think for a moment about how
> easy it is to create watchpoints.

No software technique can compare with the performance of the x86's hardware
watchpoints.  They are amazingly useful, especially in complex cases where a
2x, 10x, or 100x slowdown would preclude debugging at all.

Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html

[toc] | [prev] | [next] | [standalone]

#19979 — Re: OT: ANS Forth

Andy Valencia wrote:

> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> For goodness' sake, this is Forth!  Just think for a moment about how
>> easy it is to create watchpoints.
> 
> No software technique can compare with the performance of the x86's
> hardware watchpoints.

Well, do it the Forth way, and solve only the trivial problem: The variable 
is accessed with <name> !.  How to implement a watchpoint?  Well, define 
<name> in such a way that it checks for a following !.  If there is one, 
compile the watchpoint ! (which displays the variable name, and the from->to 
change), otherwise, continue as usual.  An analytic compiler can catch quite 
a lot of cases even when the ! isn't directly after the variable name.

This is more bullet-proof to do with values, as you absolutely need a TO to 
change a value.

That way, you can observe 100s of variables, without slowing down accesses 
to any other variable.

The slower way, which is more general, is to pack all watched variables into 
a specific memory area (trivial), and add code to every ! to check for that 
area.  If you like a combination with hardware assistance, you could 
mprotect all your watched variables as read-only, and if the access 
segfaults, print the diagnistics, mprotect rw, single-step one instruction, 
and mprotect to ro again.  That way, your check is outside !, and you have 
full speed of all non-watched variables.

> They are amazingly useful, especially in complex cases where
> a 2x, 10x, or 100x slowdown would preclude debugging at all.

Yes.  And they work for any arbitrary pointer calculations, as well as for 
buffer overflows accidently killing the variable, which no software 
technique in the world will discover.  But there are just a handful of these 
watchpoint registers.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#20023 — Re: OT: ANS Forth

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Andy Valencia wrote:
>
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> For goodness' sake, this is Forth!  Just think for a moment about how
>>> easy it is to create watchpoints.
>> 
>> No software technique can compare with the performance of the x86's
>> hardware watchpoints.
>
>Well, do it the Forth way, and solve only the trivial problem: The variable 
>is accessed with <name> !.  How to implement a watchpoint?  Well, define 
><name> in such a way that it checks for a following !.

Brr.

>This is more bullet-proof to do with values, as you absolutely need a TO to 
>change a value.

No, there is another way: store to a buggy address.

>The slower way, which is more general, is to pack all watched variables into 
>a specific memory area (trivial), and add code to every ! to check for that 
>area.  If you like a combination with hardware assistance, you could 
>mprotect all your watched variables as read-only, and if the access 
>segfaults, print the diagnistics, mprotect rw, single-step one instruction, 
>and mprotect to ro again.

Sounds too complicated and may also be quite slow.  Given that ! is
not so frequent in Forth, a check for a simple addres of a range
should not produce a big slowdown.  There are a few other primitives
that store to memory (+! MOVE CMOVE CMOVE> READ-FILE, READ-LINE, any
others?), one would have to add checks to all of them.

>Yes.  And they work for any arbitrary pointer calculations, as well as for 
>buffer overflows accidently killing the variable, which no software 
>technique in the world will discover.

Sure, if you cover every one of these primitives, you are pretty safe;
ok, a stack could overflow into the place you want to watch if you
allow setting a stack pointer in the vicinity, but you can protect
against that, too.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#20028 — Re: OT: ANS Forth

Anton Ertl wrote:
>>This is more bullet-proof to do with values, as you absolutely need a TO
>>to change a value.
> 
> No, there is another way: store to a buggy address.

Or buffer overflows or whatever writes where it shouldn't.

>>The slower way, which is more general, is to pack all watched variables
>>into a specific memory area (trivial), and add code to every ! to check
>>for that
>>area.  If you like a combination with hardware assistance, you could
>>mprotect all your watched variables as read-only, and if the access
>>segfaults, print the diagnistics, mprotect rw, single-step one
>>instruction, and mprotect to ro again.
> 
> Sounds too complicated and may also be quite slow.

The print statement for the diagnostics won't be that fast, either.  You 
have a read-only page, all reads go without delay, and the write is 
segfault+mprotect+single step+mprotect+return from segfault.

Given that you need the OS to set the debug registers, too, this is not any 
slower than using debug registers.

> Given that ! is
> not so frequent in Forth, a check for a simple addres of a range
> should not produce a big slowdown.  There are a few other primitives
> that store to memory (+! MOVE CMOVE CMOVE> READ-FILE, READ-LINE, any
> others?), one would have to add checks to all of them.

If you can make sure that only primitives can access memory, this is 
sufficent.  What about a C interface?

>>Yes.  And they work for any arbitrary pointer calculations, as well as for
>>buffer overflows accidently killing the variable, which no software
>>technique in the world will discover.
> 
> Sure, if you cover every one of these primitives, you are pretty safe;
> ok, a stack could overflow into the place you want to watch if you
> allow setting a stack pointer in the vicinity, but you can protect
> against that, too.

What might be interesting for primitive-supported watchpoints is to 
integrate the tracing, e.g. into a memory buffer.  If you want to record 
significant traces, and observe many variables, the primitive-supported 
trace would be the way to go.

Bill Stoddard does something like this for his reversible Forth: Each store 
records the previous value and the address in the roll-back buffer.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#20175 — Re: OT: ANS Forth

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>>>The slower way, which is more general, is to pack all watched variables
>>>into a specific memory area (trivial), and add code to every ! to check
>>>for that
>>>area.  If you like a combination with hardware assistance, you could
>>>mprotect all your watched variables as read-only, and if the access
>>>segfaults, print the diagnistics, mprotect rw, single-step one
>>>instruction, and mprotect to ro again.
>> 
>> Sounds too complicated and may also be quite slow.
>
>The print statement for the diagnostics won't be that fast, either.

Yes, but you probably will be selective in what you print, because you
then have to scan through it.

Whereas you may not have much choice in what you watch, and the page
granularity means that you will probably get a lot of collateral page
faults (and it's not always practical to arrange the data in a way
that avoids this).

>  You 
>have a read-only page, all reads go without delay, and the write is 
>segfault+mprotect+single step+mprotect+return from segfault.

Could mean a factor 1000 or more slowdown for ! etc. that hits the
page.

>If you can make sure that only primitives can access memory, this is 
>sufficent.  What about a C interface?

Yes, that's always the Achilles heel of VM based approaches.  They
only work for stuff that stays in the VM.  Hmm, maybe save (or
checksum) the memory before leaving the VM and check it when execution
returns to the VM.

>What might be interesting for primitive-supported watchpoints is to 
>integrate the tracing, e.g. into a memory buffer.  If you want to record 
>significant traces, and observe many variables, the primitive-supported 
>trace would be the way to go.

I see these as independent features.  Not sure what you have in mind
here.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#20179 — Re: OT: ANS Forth

Anton Ertl wrote:
>>The print statement for the diagnostics won't be that fast, either.
> 
> Yes, but you probably will be selective in what you print, because you
> then have to scan through it.
> 
> Whereas you may not have much choice in what you watch, and the page
> granularity means that you will probably get a lot of collateral page
> faults (and it's not always practical to arrange the data in a way
> that avoids this).

Yes, but the main idea *was* to arrange it in a way that avoids that.  
Especially with named variables, you can easily put those you want to watch 
into the watched region, and the others will be free of charge.

>>What might be interesting for primitive-supported watchpoints is to
>>integrate the tracing, e.g. into a memory buffer.  If you want to record
>>significant traces, and observe many variables, the primitive-supported
>>trace would be the way to go.
> 
> I see these as independent features.  Not sure what you have in mind
> here.

Things like Verilog waveforms.  You trace many variables (maybe even all, 
and then you can just prepare to trace everything, because it's cheaper than 
to check if you want to trace), and later look selectively at what your 
program has done.  A watchpoint with a printf() statement or TYPE costs 
easily 1000s of cycles.  A ! primitive with a to-memory trace functionality 
costs a few additional cycles.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#20204 — Re: OT: ANS Forth

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>>>The print statement for the diagnostics won't be that fast, either.
>> 
>> Yes, but you probably will be selective in what you print, because you
>> then have to scan through it.
>> 
>> Whereas you may not have much choice in what you watch, and the page
>> granularity means that you will probably get a lot of collateral page
>> faults (and it's not always practical to arrange the data in a way
>> that avoids this).
>
>Yes, but the main idea *was* to arrange it in a way that avoids that.  
>Especially with named variables, you can easily put those you want to watch 
>into the watched region, and the others will be free of charge.

Yes, but if you want to watch some cell in an ALLOCATEd structure, it's not very practical to avoid collateral page faults.

>You trace many variables (maybe even all, 
>and then you can just prepare to trace everything, because it's cheaper than 
>to check if you want to trace), and later look selectively at what your 
>program has done.  A watchpoint with a printf() statement or TYPE costs 
>easily 1000s of cycles.  A ! primitive with a to-memory trace functionality 
>costs a few additional cycles.

Yes, that would be quite a different kind of beast: Instead of
selective tracing and then looking at the output directly or with an
editor, you trace everything and have tools for selectively displaying
the interesting parts of the trace.  Not sure if it's better.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#19985 — Re: OT: ANS Forth

Andy Valencia <user@vsta.org> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> For goodness' sake, this is Forth!  Just think for a moment about how
>> easy it is to create watchpoints.
> 
> No software technique can compare with the performance of the x86's
> hardware watchpoints.  They are amazingly useful, especially in
> complex cases where a 2x, 10x, or 100x slowdown would preclude
> debugging at all.

Yes, and if you have hardware watch registers, of course you use them;
why would you not?  But if you don't have them, the last thing you
want to do is excruciatingly slowly single-step via ptrace() waiting
for a memory location to change.

Andrew.

[toc] | [prev] | [next] | [standalone]

#19702 — Re: OT: ANS Forth

Ed <invalid@nospam.com> wrote:
> Elizabeth D. Rather wrote:
>> Yes, there are some languages and OSs with single "czars". But
>> those that have survived have benefitted from a leader who can
>> consider these wider issues and needs, and keep an open ear to user
>> input. Chuck tried that for a while, but it didn't work for him, so
>> he took a different path.
> 
> But a Standard based on who's principles if not Chuck's?  Or is no
> principle involved at all - just a vote by persons with vested
> interests whose ideas change with each new TC that comes along?

I believe I already answered this question on Dec 22 last year.

https://groups.google.com/group/comp.lang.forth/msg/451d0cab09a21d9e?dmode=source&output=gplain&noredirect&pli=1

Andrew.

[toc] | [prev] | [next] | [standalone]

#19703 — Re: OT: ANS Forth

On Wed, 13 Feb 2013 11:42:58 +1100, "Ed" <invalid@nospam.com> wrote:

>Chuck stated in a 2009 interview:
>
>"Forth has gradually become more complicated to suit the taste of
> contemporary programmers and the complexity of modern computers."
>
>It was not a compliment.

and the complexity of modern applications ...

As application complexity has grown (enourmously), so the minimum
level at which application programmers are prepared to start has also
risen greatly. That minimum level has to be supplied.

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]

#19632 — Re: OT: ANS Forth

"Ed" <invalid@nospam.com> writes:
>Elizabeth D. Rather wrote:
>> On 2/9/13 6:27 AM, Zbiggy wrote:
>> > Actually, on IsForth doc-pages I've found an interesting quote:
>> >
>> > "The ans Forth standard does NOT describe the Forth language but a language
>> > of the same name" (Chuck Moore)
[...]
>Perhaps we can discover what Forth is by looking at what
>has remained constant throughout Chuck's Forths e.g. stack-based RPN
>language,

ANS Forth satisfies that.

> few types,

Types are mainly in the mind of the programmer, that's true of Chuck
Moore's Forths as well as ANS Forth.

> basic constructs,

I have no idea what you mean here, so I cannot comment on that.

> simple compiler,

Possible, but not required by ANS Forth.

> small size,

A no-frills implementation of the Core wordset is pretty small,
although minimalists still find unnecessary words (and people who
prefer full-featured systems will find it useless, so such a thing
would be neither here nor there).

> few
>cosmetics,

I have no idea what you mean here, so I cannot comment on that.

> no locals ...

Would be satisfied by any implementation that does not implement the
locals wordset or any other locals facility, e.g., the hypothetical
no-frills implementation.

> and he still likes screens.

Ok, for that one would have to get away from the core-only
implementation and add the blocks wordset.

So, a no-frills implementation of the core+blocks word sets with a
simple compiler would satisfy both your presumed requirements of Chuck
Moore and the ANS Forth spec.

But maybe the statement was not about what has been constant
throughout Chucks Forths, but simply a statement about his view of
Forth at the time of the statement (which may have been cmForth,
machine Forth, colorForth, or whatever; neither of these were ANS
Forth compliant, although the influences of cmForth are visible in
parts of the standard.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8  Next page →

Back to top | Article view | comp.lang.forth

csiph-web