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

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

Compiled Forth

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

Contents

  Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-04 12:02 -0700
    Re: Compiled Forth "Elizabeth D. Rather" <erather@forth.com> - 2015-04-04 14:43 -1000
      Re: Compiled Forth hughaguilar96@gmail.com - 2015-04-04 18:16 -0700
        Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-05 10:58 -0700
      Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-05 10:52 -0700
        Re: Compiled Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-06 15:35 +0000
          Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-06 08:51 -0700
            Re: Compiled Forth mhx@iae.nl - 2015-04-06 15:32 -0700
              Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-06 16:28 -0700
                Re: Compiled Forth mhx@iae.nl - 2015-04-08 13:58 -0700
                  Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-08 14:41 -0700
                    Re: Compiled Forth "Elizabeth D. Rather" <erather@forth.com> - 2015-04-08 14:01 -1000
                      Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-09 00:06 -0700
                      Re: Compiled Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-10 16:48 +0000
                        Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 10:23 -0700
                          Re: Compiled Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-10 18:04 +0000
                  Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-09 10:31 -0700
                    Re: Compiled Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-09 17:57 +0000
                      Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-09 11:06 -0700
                      Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-22 09:17 -0700
          Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-06 09:01 -0700
    Re: Compiled Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-05 09:32 +0000
      Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-05 11:02 -0700
        Re: Compiled Forth "HAA" <someone@microsoft.com> - 2015-04-06 18:35 +1000
    Re: Compiled Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-05 09:52 +0000
      Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-05 11:20 -0700
      Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-05 11:57 -0700
        Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-05 12:05 -0700
          Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-05 12:47 -0700
            Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-05 13:36 -0700
              Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-05 13:57 -0700
                Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-05 14:37 -0700
                  Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-05 15:10 -0700
                    Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-05 15:23 -0700
        Re: Compiled Forth Ron Aaron <rambamist@gmail.com> - 2015-04-06 08:52 +0300
          Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-05 23:09 -0700
            Re: Compiled Forth Ron Aaron <rambamist@gmail.com> - 2015-04-06 10:12 +0300
            Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-06 00:15 -0700
              Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-06 01:05 -0700
                Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-06 01:27 -0700
              Re: Compiled Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-06 12:20 +0000
            Re: Compiled Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-06 12:10 +0000
              Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-06 11:45 -0700
                Re: Compiled Forth Melzzzzz <mel@zzzzz.com> - 2015-04-06 21:16 +0200
                  Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-06 12:55 -0700
          Re: Compiled Forth Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-06 09:01 +0100
            Re: Compiled Forth Ron Aaron <rambamist@gmail.com> - 2015-04-06 11:27 +0300
        Re: Compiled Forth Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-06 08:06 +0100
        Re: Compiled Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-06 14:15 +0000
    Re: Compiled Forth stephen@mpeforth.com (Stephen Pelc) - 2015-04-06 11:32 +0000
    Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-06 08:01 -0700
      Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-06 12:04 -0700
        Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-06 12:58 -0700
          Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-06 13:29 -0700
            Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-06 16:44 -0700
              Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-06 19:59 -0700
                Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-07 01:31 -0700
                  Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-07 01:36 -0700
                  Re: Compiled Forth Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-07 12:00 +0100
                    Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-07 04:25 -0700
                      Proposal for ALLOCATEd bignum's Re: Compiled Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-07 12:41 +0000
                      Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-08 21:40 -0700
                        Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-09 00:18 -0700
                  Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-09 23:43 -0700
                    Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 04:07 -0700
                      Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 04:37 -0700
                    Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 04:45 -0700
                      Re: Compiled Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-10 12:02 +0000
                        Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 07:21 -0700
                          Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 07:53 -0700
                            Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 09:43 -0700
                            Re: Compiled Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-10 16:43 +0000
                              Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 11:03 -0700
                                Re: Compiled Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-10 18:26 +0000
                                Re: Compiled Forth mhx@iae.nl - 2015-04-10 11:27 -0700
                                  Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 11:36 -0700
                                    Re: Compiled Forth mhx@iae.nl - 2015-04-10 11:56 -0700
                                    Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-10 12:20 -0700
                                      Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 13:00 -0700
                                        Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-10 13:14 -0700
                                          Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 13:29 -0700
                                            Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-10 16:08 -0700
                                              Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 23:08 -0700
                                        Re: Compiled Forth mhx@iae.nl - 2015-04-11 01:59 -0700
                                          Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-11 02:20 -0700
                                          Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-11 02:44 -0700
                                            Re: Compiled Forth mhx@iae.nl - 2015-04-11 11:21 -0700
                                        Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-11 11:43 -0700
                                          Re: Compiled Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-11 19:44 +0000
                                            Re: Compiled Forth Paul Rubin <no.email@nospam.invalid> - 2015-04-11 12:51 -0700
                                              Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-11 15:26 -0700
                    Re: Compiled Forth lehs <skydda.barnen@gmail.com> - 2015-04-10 04:50 -0700

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

#38014

Den måndag 6 april 2015 kl. 17:40:25 UTC+2 skrev Anton Ertl:
> lehs <skydda.barnen@gmail.com> writes:
> >The gap of 20 times might come from extensive use of CMOVE in the big numbe=
> >r routines..?
> 
> Unless CMOVE is implemented in high-level Forth in the non-optimizing
> variant and implemented with the appropriate machine instruction in
> the optimizing variant, I would not expect that it's CMOVE.  
> 
> Anyway, I certainly would be interested in your benchmark.  I hope
> it's portable.
> 
> - anton
> -- 
> M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
>      New standard: http://www.forth200x.org/forth200x.html
>    EuroForth 2014: http://www.euroforth.org/ef14/

I think I was wrong about that CMOVE (I thought you commented an other post). Probably the 20 times gap come from the fact that the top words (B+, B* etc) is build from other a lot of other words and when using it in the test below give a big gap:

HEX 

: DIG>PAD \ s -- 
  >A PAD 1+! PAD C@ PAD + C! ;

: RAN>PAD \ s# --	s#<256
  PAD 0! 0 DO 0A RANDOM DIG>PAD LOOP ;

: RAN>B \ s# --		s#<256
  RAN>PAD PAD COUNT VPUSH V>B ;

: TEST/ \ s# n --	s#<256	test of B/MOD
  RESET_SEED 0
  DO DUP RAN>B DUP RAN>B BGCD BDROP
  LOOP DROP ;

: TEST* \ s# n -- 	s#<256
  RESET_SEED 0
  DO DUP RAN>B DUP RAN>B DUP RAN>B B**MOD BDROP
  LOOP DROP ;

DECIMAL

I used 

70 10000 TEST/
and
70 100 TEST*

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

#37958

lehs <skydda.barnen@gmail.com> writes:
>I'm using an old laptop with a simple Celeron processor and SP-Forth from t=
>he Russian Forth Interest Group. In SP-Forth there are words SET-OPT and DI=
>S-OPT that optionally compile the Forth code to machine code. Using this op=
>timization method the code normally become 20 times faster.=20
>
>I wonder, is this normal for a processor like mine? It's a rather big gap i=
>n my opinion...

Depends on how slow SP-Forth is otherwise.  The usual gap between e.g.
Gforth and VFX is much smaller.

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

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

#37969

Den söndag 5 april 2015 kl. 11:34:34 UTC+2 skrev Anton Ertl:
> lehs <skydda.barnen@gmail.com> writes:
> >I'm using an old laptop with a simple Celeron processor and SP-Forth from t=
> >he Russian Forth Interest Group. In SP-Forth there are words SET-OPT and DI=
> >S-OPT that optionally compile the Forth code to machine code. Using this op=
> >timization method the code normally become 20 times faster.=20
> >
> >I wonder, is this normal for a processor like mine? It's a rather big gap i=
> >n my opinion...
> 
> Depends on how slow SP-Forth is otherwise.  The usual gap between e.g.
> Gforth and VFX is much smaller.
> 
> - anton
> -- 
> M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
>      New standard: http://www.forth200x.org/forth200x.html
>    EuroForth 2014: http://www.euroforth.org/ef14/

It seems that I have used an unorthodox benchmark and with a classical bubble sort the gap become less, about 2.75 times.

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

#38002

lehs wrote:
> ...
> Using this optimization method the code normally become 20 times faster.
> ....
> It seems that I have used an unorthodox benchmark and with a classical bubble sort the
> gap become less, about 2.75 times.

There is no "unorthodox benchmark".  The results are what they are.

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

#37959

In article <ae5a0147-ac8e-4dc9-ae19-9f67b39bca0a@googlegroups.com>,
lehs  <skydda.barnen@gmail.com> wrote:
>I'm using an old laptop with a simple Celeron processor and
>SP-Forth from the Russian Forth Interest Group. In SP-Forth there
>are words SET-OPT and DIS-OPT that optionally compile the Forth
>code to machine code. Using this optimization method the code
>normally become 20 times faster.
>
>I wonder, is this normal for a processor like mine? It's a rather
>big gap in my opinion...

You could show us some disassembled code. I wouldn't be surprised
if SP-Forth unoptimized would run about customary for threaded
code (say like ciforth). And I wouldn't be surprised if you Russians
had a very clever optimizer that would be on a par with say
Intel's c compiler on a bad day or even a good day.

By the way, I would be interested to have your bignums integrated
in ciforth. That would mean replacing the lowest layer with
transparant allocation and allocation under the hood, and
denotations for bignums. Where ciforth has a small ALLOCATE that
would mean it could become part of the package. I estimate that
2/3 of the package would be dropped, exactly the part that doesn't
run on ciforth ...

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]

#37971

Den söndag 5 april 2015 kl. 11:52:48 UTC+2 skrev Albert van der Horst:
> In article <ae5a0147-ac8e-4dc9-ae19-9f67b39bca0a@googlegroups.com>,
> lehs  <skydda.barnen@gmail.com> wrote:
> >I'm using an old laptop with a simple Celeron processor and
> >SP-Forth from the Russian Forth Interest Group. In SP-Forth there
> >are words SET-OPT and DIS-OPT that optionally compile the Forth
> >code to machine code. Using this optimization method the code
> >normally become 20 times faster.
> >
> >I wonder, is this normal for a processor like mine? It's a rather
> >big gap in my opinion...
> 
> You could show us some disassembled code. I wouldn't be surprised
> if SP-Forth unoptimized would run about customary for threaded
> code (say like ciforth). And I wouldn't be surprised if you Russians
> had a very clever optimizer that would be on a par with say
> Intel's c compiler on a bad day or even a good day.
> 
> By the way, I would be interested to have your bignums integrated
> in ciforth. That would mean replacing the lowest layer with
> transparant allocation and allocation under the hood, and
> denotations for bignums. Where ciforth has a small ALLOCATE that
> would mean it could become part of the package. I estimate that
> 2/3 of the package would be dropped, exactly the part that doesn't
> run on ciforth ...
> 
> 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

Hi Albert!

First, I would be delighted if you integrated the big number routines in your ciforth. There are some bugs left, I believe, but I'm satisfied with the result of the reorganization. I think this is the final one, but of course many of the words could be improved later on.

The Russians impress on me to. There seems to be a lot of smart solutions in the package. Is there any special word or kind of world that you would like to see disassembled? As far as I understand, I don't do assembler code no more after seen how easy it could have been with orthogonal micro-codes in Forth, but it seems as the code is compact.

If you would like to discuss big numbers in ciforth you could also mail to me on lehs@h*tmail.se

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

#37973

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
> By the way, I would be interested to have your bignums integrated
> in ciforth. That would mean replacing the lowest layer with
> transparant allocation ... ciforth has a small ALLOCATE

I don't see a reasonable way to do this without garbage collection.
How are you going to free the bignums?

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

#37974

Den söndag 5 april 2015 kl. 20:57:49 UTC+2 skrev Paul Rubin:
> albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
> > By the way, I would be interested to have your bignums integrated
> > in ciforth. That would mean replacing the lowest layer with
> > transparant allocation ... ciforth has a small ALLOCATE
> 
> I don't see a reasonable way to do this without garbage collection.
> How are you going to free the bignums?

In my system I avoid garbage collection while using the typical Forth stack organizing style. It's simple and works rather good. But of course it's not optimal to SWAP and ROT several hundred digit numbers...

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

#37976

lehs <skydda.barnen@gmail.com> writes:
> In my system I avoid garbage collection while using the typical Forth
> stack organizing style. It's simple and works rather good. But of
> course it's not optimal to SWAP and ROT several hundred digit
> numbers...

Do you mean that you copy the entire numbers all over the place?  What
do you do if you want to store one in the middle of some kind of buffer
or structure?  I may have misinterpreted Albert's post but I thought he
was only going to copy references.  GC is the best way I can see to do
this.  

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

#37979

Den söndag 5 april 2015 kl. 21:47:27 UTC+2 skrev Paul Rubin:
> lehs <skydda.barnen@gmail.com> writes:
> > In my system I avoid garbage collection while using the typical Forth
> > stack organizing style. It's simple and works rather good. But of
> > course it's not optimal to SWAP and ROT several hundred digit
> > numbers...
> 
> Do you mean that you copy the entire numbers all over the place?  What
> do you do if you want to store one in the middle of some kind of buffer
> or structure?  I may have misinterpreted Albert's post but I thought he
> was only going to copy references.  GC is the best way I can see to do
> this.

I'm not sure what Albert intend to do but I use a stack for numbers of dynamical length and use the stack in a normal way. The world BOVER, corresponding to OVER, make a copy of the second number on the stack on the top of the stack.

Do you mean that it is possible to use a reference stack coordinated with a list structure of numbers, so that stack manipulation of the reference stack in computations is coordinated with handling of data in the list?

How to interpret a reference dropping?

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

#37980

lehs <skydda.barnen@gmail.com> writes:
> I'm not sure what Albert intend to do but I use a stack for numbers of
> dynamical length and use the stack in a normal way. The world BOVER,
> corresponding to OVER, make a copy of the second number on the stack
> on the top of the stack.

How do you store a number in a variable?

> Do you mean that it is possible to use a reference stack coordinated
> with a list structure of numbers, so that stack manipulation of the
> reference stack in computations is coordinated with handling of data
> in the list?

Yes, it's just the ordinary data stack.  The values on it are pointers
to bignums that are allocated in memory.  DUP just duplicates such a
pointer if that's what's on the top of the stack.  Adding two bignums
with + allocates storage for a new bignum, computes the sum there,
pops the two old pointers and pushes the new one.

> How to interpret a reference dropping?

http://www.complang.tuwien.ac.at/forth/garbage-collection.zip

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

#37981

Den söndag 5 april 2015 kl. 22:57:28 UTC+2 skrev Paul Rubin:
> lehs <skydda.barnen@gmail.com> writes:
> > I'm not sure what Albert intend to do but I use a stack for numbers of
> > dynamical length and use the stack in a normal way. The world BOVER,
> > corresponding to OVER, make a copy of the second number on the stack
> > on the top of the stack.
> 
> How do you store a number in a variable?
> 
> > Do you mean that it is possible to use a reference stack coordinated
> > with a list structure of numbers, so that stack manipulation of the
> > reference stack in computations is coordinated with handling of data
> > in the list?
> 
> Yes, it's just the ordinary data stack.  The values on it are pointers
> to bignums that are allocated in memory.  DUP just duplicates such a
> pointer if that's what's on the top of the stack.  Adding two bignums
> with + allocates storage for a new bignum, computes the sum there,
> pops the two old pointers and pushes the new one.
> 
> > How to interpret a reference dropping?
> 
> http://www.complang.tuwien.ac.at/forth/garbage-collection.zip

I do understand how to add numbers using references, but not how the flow will work in programs - if I want to write normal Forth words and make them work? Should a GC check the list for references not existing in the stack? And link away such data?

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

#37984

lehs <skydda.barnen@gmail.com> writes:
> I do understand how to add numbers using references, but not how the
> flow will work in programs - if I want to write normal Forth words and
> make them work? Should a GC check the list for references not existing
> in the stack? And link away such data?

Anton's GC scans the entire stack and data heap for anything that looks
like a pointer.  You just write Forth words the usual way, with normal
data cells.  You would either change the way arithmetic and integer
literals work, or add some new words for dealing wiht bignum references
independently of regular integer cells.  You can store references into
variables without doing anything special, except I guess you have to
declare the variables to tell the gc to consider them permanently
accessible.  If you want to get rid of a reference, just use DROP, or
overwrite it, or whatever.  There might or might not be other references
to that number still alive elsewhere.  After a while, the gc will scan
memory and figure out if there are more references to the number.  If
there are none, it reclaims the memory.    

GC of this sort has the potential to leak memory, and it has the
notorious drawback of occasionally pausing the application while the gc
runs.  So you can't use it in real-time applications, and you might
occasionally notice a slight hiccup in interactive programs.

The gc.html file in the zip archive whose url I posted has more info and
is worth reading if you're unfamiliar with gc.  Gc is heavily disfavored
in a lot of the Forth world, and there are definitely situations where
it's inappropriate, but your application can get away with using it, it
makes programming a lot easier.

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

#37985

Den måndag 6 april 2015 kl. 00:10:17 UTC+2 skrev Paul Rubin:
> lehs <skydda.barnen@gmail.com> writes:
> > I do understand how to add numbers using references, but not how the
> > flow will work in programs - if I want to write normal Forth words and
> > make them work? Should a GC check the list for references not existing
> > in the stack? And link away such data?
> 
> Anton's GC scans the entire stack and data heap for anything that looks
> like a pointer.  You just write Forth words the usual way, with normal
> data cells.  You would either change the way arithmetic and integer
> literals work, or add some new words for dealing wiht bignum references
> independently of regular integer cells.  You can store references into
> variables without doing anything special, except I guess you have to
> declare the variables to tell the gc to consider them permanently
> accessible.  If you want to get rid of a reference, just use DROP, or
> overwrite it, or whatever.  There might or might not be other references
> to that number still alive elsewhere.  After a while, the gc will scan
> memory and figure out if there are more references to the number.  If
> there are none, it reclaims the memory.    
> 
> GC of this sort has the potential to leak memory, and it has the
> notorious drawback of occasionally pausing the application while the gc
> runs.  So you can't use it in real-time applications, and you might
> occasionally notice a slight hiccup in interactive programs.
> 
> The gc.html file in the zip archive whose url I posted has more info and
> is worth reading if you're unfamiliar with gc.  Gc is heavily disfavored
> in a lot of the Forth world, and there are definitely situations where
> it's inappropriate, but your application can get away with using it, it
> makes programming a lot easier.

Thanks for the information! I'll have to reconsider then. Damn, just as I thought I was done! )-:

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

#37991

On 4/5/15 21:57, Paul Rubin wrote:
> albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>> By the way, I would be interested to have your bignums integrated
>> in ciforth. That would mean replacing the lowest layer with
>> transparant allocation ... ciforth has a small ALLOCATE
>
> I don't see a reasonable way to do this without garbage collection.
> How are you going to free the bignums?

That's why 8th uses reference-counted GC.  Items (strings, numbers, etc) 
are allocated from pools of that kind of item.  When an item's reference 
count returns to 0, it is cleaned-up (deallocated, resources released, 
etc).  The items inside the pools themselves are not deallocated until 
the program quits, though.

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

#37992

Ron Aaron <rambamist@gmail.com> writes:
>>> ciforth has a small ALLOCATE
>> I don't see a reasonable way to do this without garbage collection.
>> How are you going to free the bignums?
> That's why 8th uses reference-counted GC.  Items (strings, numbers,
> etc) are allocated from pools of that kind of item....

Ok, but that is basically Lisp in the sense that you can know the type
of every object at runtime.  I don't see how to do integrated bignums
sanely with reference counting in a regular Forth which uses untyped
data and pointers everywhere, and whose low level interpreter has words
like DUP or DROP which do a few simple machine instructions and would
take a speed and complexity hit if they also messed with ref counts.

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

#37994

On 4/6/15 09:09, Paul Rubin wrote:
> Ron Aaron <rambamist@gmail.com> writes:

> Ok, but that is basically Lisp in the sense that you can know the type
> of every object at runtime.  I don't see how to do integrated bignums
> sanely with reference counting in a regular Forth which uses untyped
> data and pointers everywhere, and whose low level interpreter has words
> like DUP or DROP which do a few simple machine instructions and would
> take a speed and complexity hit if they also messed with ref counts.

Yes, there's clearly a speed-hit you have to take for ref counts.  I was 
willing to take it in 8th because I'm aiming for a different target 
audience than traditional Forths.

However, you can accomplish much the same thing by allocating a chunk of 
memory for your bignum and not trying to reclaim the memory; not a good 
solution if you may run out of memory, but certainly faster than dealing 
with ref counts or continual alloc/free

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

#37996

> I don't see how to do integrated bignums
> sanely with reference counting in a regular Forth which uses untyped
> data and pointers everywhere, and whose low level interpreter has words
> like DUP or DROP which do a few simple machine instructions and would
> take a speed and complexity hit if they also messed with ref counts.

Why don't use "typed stacks", special stacks for references that replaces parameter stacks and local variables for bignums? So that every ref to a bignum must be stored in a bignum stack.

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

#37998

lehs <skydda.barnen@gmail.com> writes:
> Why don't use "typed stacks", special stacks for references that
> replaces parameter stacks and local variables for bignums? So that
> every ref to a bignum must be stored in a bignum stack.

What about bignum variables, arrays of bignums, structures containing
various types of data including bignums, etc.?

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

#37999

Den måndag 6 april 2015 kl. 10:05:42 UTC+2 skrev Paul Rubin:
> lehs <skydda.barnen@gmail.com> writes:
> > Why don't use "typed stacks", special stacks for references that
> > replaces parameter stacks and local variables for bignums? So that
> > every ref to a bignum must be stored in a bignum stack.
> 
> What about bignum variables, arrays of bignums, structures containing
> various types of data including bignums, etc.?

Global arrays and stacks would be enough for me to be "typed" bignum.

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

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

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

csiph-web