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

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

Josephus Circle problem

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

Contents

  Josephus Circle problem Paul Rubin <no.email@nospam.invalid> - 2013-12-23 19:12 -0800
    Re: Josephus Circle problem "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-24 02:49 -0500
      Re: Josephus Circle problem Paul Rubin <no.email@nospam.invalid> - 2013-12-24 01:13 -0800
        Re: Josephus Circle problem mhx@iae.nl - 2013-12-24 02:17 -0800
          Re: Josephus Circle problem ForthFreak <forthfreak@gmail.com> - 2013-12-24 03:45 -0800
            Re: Josephus Circle problem Paul Rubin <no.email@nospam.invalid> - 2013-12-24 04:25 -0800
              Re: Josephus Circle problem ForthFreak <forthfreak@gmail.com> - 2013-12-24 04:25 -0800
                Re: Josephus Circle problem Paul Rubin <no.email@nospam.invalid> - 2013-12-24 04:52 -0800
              Re: Josephus Circle problem albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-24 14:57 +0000
              Re: Josephus Circle problem "Ed" <invalid@invalid.com> - 2013-12-25 20:15 +1100
            Re: Josephus Circle problem mhx@iae.nl - 2013-12-24 04:36 -0800
        Re: Josephus Circle problem "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-24 17:05 -0500
        Re: Josephus Circle problem "WJ" <w_a_x_man@yahoo.com> - 2014-03-10 07:11 +0000
      Re: Josephus Circle problem mhx@iae.nl - 2013-12-24 02:59 -0800
    Re: Josephus Circle problem ForthFreak <forthfreak@gmail.com> - 2013-12-24 01:53 -0800
      Re: Josephus Circle problem Paul Rubin <no.email@nospam.invalid> - 2013-12-24 04:06 -0800
        Re: Josephus Circle problem ForthFreak <forthfreak@gmail.com> - 2013-12-24 04:24 -0800
    Re: Josephus Circle problem ForthFreak <forthfreak@gmail.com> - 2013-12-24 04:30 -0800
      Re: Josephus Circle problem ForthFreak <forthfreak@gmail.com> - 2013-12-24 04:35 -0800
    Re: Josephus Circle problem ForthFreak <forthfreak@gmail.com> - 2013-12-24 05:01 -0800
      Re: Josephus Circle problem Paul Rubin <no.email@nospam.invalid> - 2013-12-24 05:34 -0800
        Re: Josephus Circle problem ForthFreak <forthfreak@gmail.com> - 2013-12-24 05:22 -0800
        Re: Josephus Circle problem "Elizabeth D. Rather" <erather@forth.com> - 2013-12-24 13:25 -1000
          Re: Josephus Circle problem "Ed" <invalid@invalid.com> - 2013-12-25 20:40 +1100
            Re: Josephus Circle problem "Elizabeth D. Rather" <erather@forth.com> - 2013-12-25 09:37 -1000
              Re: Josephus Circle problem ForthFreak <forthfreak@gmail.com> - 2013-12-26 03:19 -0800
                Re: Josephus Circle problem "Elizabeth D. Rather" <erather@forth.com> - 2013-12-26 12:01 -1000
              Re: Josephus Circle problem "Ed" <invalid@invalid.com> - 2013-12-27 12:33 +1100
                Re: Josephus Circle problem Elizabeth D Rather <erather@forth.com> - 2013-12-26 17:41 -1000
                  Re: Josephus Circle problem "Ed" <invalid@invalid.com> - 2013-12-27 18:46 +1100
                    Re: Josephus Circle problem Mark Wills <markrobertwills@yahoo.co.uk> - 2013-12-27 02:46 -0800
                      Re: Josephus Circle problem albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-27 13:16 +0000
                        Re: Josephus Circle problem mhx@iae.nl - 2013-12-27 05:27 -0800
                          Re: Josephus Circle problem albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-27 14:15 +0000
                        Re: Josephus Circle problem "Ed" <invalid@invalid.com> - 2013-12-29 21:56 +1100
                          Re: Josephus Circle problem albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-29 12:37 +0000
                            Re: Josephus Circle problem "Ed" <invalid@invalid.com> - 2013-12-30 00:47 +1100
                      Re: Josephus Circle problem "Ed" <invalid@invalid.com> - 2013-12-29 14:08 +1100
                Re: Josephus Circle problem Mark Wills <markrobertwills@yahoo.co.uk> - 2013-12-27 02:35 -0800
                  Re: Josephus Circle problem Mark Wills <markrobertwills@yahoo.co.uk> - 2013-12-27 02:43 -0800
                  Re: Josephus Circle problem albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-27 19:00 +0000
      Re: Josephus Circle problem albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-24 15:59 +0000
    Re: Josephus Circle problem Gerry Jackson <spam@qlikz.org> - 2013-12-24 20:07 +0000
      Re: Josephus Circle problem albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-24 20:31 +0000
      Re: Josephus Circle problem mhx@iae.nl - 2013-12-25 04:38 -0800
        Re: Josephus Circle problem mhx@iae.nl - 2013-12-25 06:04 -0800
        Re: Josephus Circle problem mhx@iae.nl - 2013-12-25 06:06 -0800
          Re: Josephus Circle problem Paul Rubin <no.email@nospam.invalid> - 2013-12-25 23:08 -0800
            Re: Josephus Circle problem ForthFreak <forthfreak@gmail.com> - 2013-12-26 03:31 -0800
          Re: Josephus Circle problem Gerry Jackson <spam@qlikz.org> - 2013-12-26 10:52 +0000
            Re: Josephus Circle problem Tristan Plumb <firth@trstn.net> - 2013-12-26 14:37 +0000
              Re: Josephus Circle problem Paul Rubin <no.email@nospam.invalid> - 2013-12-26 07:12 -0800
            Re: Josephus Circle problem Gerry Jackson <spam@qlikz.org> - 2013-12-26 17:31 +0000
          Re: Josephus Circle problem Ron Aaron <rambamist@gmail.com> - 2013-12-26 21:39 +0200
      Re: Josephus Circle problem anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-26 17:33 +0000

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

#27429

ForthFreak <forthfreak@gmail.com> writes:
> With a slight change to use PAD. This allows one to try different
> circle sizes without need for re-compilation.

I think it's better to use ALLOT.  PAD can be as small as 64 chars.

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

#27430

On Tuesday, 24 December 2013 13:34:48 UTC, Paul Rubin  wrote:
> I think it's better to use ALLOT.  PAD can be as small as 64 chars.

How about HERE instead of PAD?

On my system PAD is generally safe. It's defined as HERE+80 so it's after user compiled code. I take your point though.

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

#27438

On 12/24/13 3:34 AM, Paul Rubin wrote:
> ForthFreak <forthfreak@gmail.com> writes:
>> With a slight change to use PAD. This allows one to try different
>> circle sizes without need for re-compilation.
>
> I think it's better to use ALLOT.  PAD can be as small as 64 chars.
>

But it almost never is, except on very limited embedded systems. 
Perfectly ok to use PAD and declare a dependency on its length being at 
least [n] bytes. Never handcuff yourself unnecessarily.

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]

#27440

Elizabeth D. Rather wrote:
> On 12/24/13 3:34 AM, Paul Rubin wrote:
> > ForthFreak <forthfreak@gmail.com> writes:
> >> With a slight change to use PAD. This allows one to try different
> >> circle sizes without need for re-compilation.
> >
> > I think it's better to use ALLOT.  PAD can be as small as 64 chars.
> >
>
> But it almost never is, except on very limited embedded systems.
> Perfectly ok to use PAD and declare a dependency on its length being at
> least [n] bytes. Never handcuff yourself unnecessarily.

Never mind size, PAD is CORE EXT and may not even exist.  Paul wins :)

BTW PAD (if it exists) is 84 chars min.

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

#27444

On 12/24/13 11:40 PM, Ed wrote:
> Elizabeth D. Rather wrote:
>> On 12/24/13 3:34 AM, Paul Rubin wrote:
>>> ForthFreak <forthfreak@gmail.com> writes:
>>>> With a slight change to use PAD. This allows one to try different
>>>> circle sizes without need for re-compilation.
>>>
>>> I think it's better to use ALLOT.  PAD can be as small as 64 chars.
>>>
>>
>> But it almost never is, except on very limited embedded systems.
>> Perfectly ok to use PAD and declare a dependency on its length being at
>> least [n] bytes. Never handcuff yourself unnecessarily.
>
> Never mind size, PAD is CORE EXT and may not even exist.  Paul wins :)
>
> BTW PAD (if it exists) is 84 chars min.

In practice, how many implementations don't support PAD? I suspect very 
few! So, you have a dependency on PAD, and that it has a certain minimum 
length. Is that likely to limit the usefulness of your code in any 
meaningful way? All you need is to add a comment to your code like:

\ Requires PAD with at least [x] bytes.

I really don't understand the philosophy of programming extra complexity 
to avoid something that is widely available and considered standard 
practice. Making a permanent allocation for an array that is really 
temporary in nature is not a "best practice".

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]

#27450

On Wednesday, 25 December 2013 19:37:45 UTC, Elizabeth D. Rather  wrote:
> I really don't understand the philosophy of programming extra complexity 
> to avoid something that is widely available and considered standard 
> practice. Making a permanent allocation for an array that is really 
> temporary in nature is not a "best practice".


Hence my suggestion to use PAD; though perhaps HERE might have been a better option.

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

#27464

On 12/26/13 1:19 AM, ForthFreak wrote:
> On Wednesday, 25 December 2013 19:37:45 UTC, Elizabeth D. Rather  wrote:
>> I really don't understand the philosophy of programming extra complexity
>> to avoid something that is widely available and considered standard
>> practice. Making a permanent allocation for an array that is really
>> temporary in nature is not a "best practice".
>
>
> Hence my suggestion to use PAD; though perhaps HERE might have been a better option.
>

HERE is used by many systems. PAD, however, is explicitly a scratch area 
for applications. Systems aren't supposed to used it. So it would be a 
better option.

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]

#27467

Elizabeth D. Rather wrote:
> On 12/24/13 11:40 PM, Ed wrote:
> > Elizabeth D. Rather wrote:
> >> On 12/24/13 3:34 AM, Paul Rubin wrote:
> >>> ForthFreak <forthfreak@gmail.com> writes:
> >>>> With a slight change to use PAD. This allows one to try different
> >>>> circle sizes without need for re-compilation.
> >>>
> >>> I think it's better to use ALLOT.  PAD can be as small as 64 chars.
> >>>
> >>
> >> But it almost never is, except on very limited embedded systems.
> >> Perfectly ok to use PAD and declare a dependency on its length being at
> >> least [n] bytes. Never handcuff yourself unnecessarily.
> >
> > Never mind size, PAD is CORE EXT and may not even exist.  Paul wins :)
> >
> > BTW PAD (if it exists) is 84 chars min.
>
> In practice, how many implementations don't support PAD? I suspect very
> few! So, you have a dependency on PAD, and that it has a certain minimum
> length. Is that likely to limit the usefulness of your code in any
> meaningful way? All you need is to add a comment to your code like:
>
> \ Requires PAD with at least [x] bytes.
>
> I really don't understand the philosophy of programming extra complexity
> to avoid something that is widely available and considered standard
> practice. Making a permanent allocation for an array that is really
> temporary in nature is not a "best practice".

For all you know PAD is itself a permanent allocation.  Data space created
with ALLOT can always be un-ALLOTed after the program is run.

If a program is to be portable and run on as many systems and as possible,
with as few dependencies as possible, and what's in CORE suffices or is
in fact better - is that not "best practice" ?

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

#27468

On 12/26/2013 3:33 PM, Ed wrote:
> Elizabeth D. Rather wrote:
>> On 12/24/13 11:40 PM, Ed wrote:
>>> Elizabeth D. Rather wrote:
>>>> On 12/24/13 3:34 AM, Paul Rubin wrote:
>>>>> ForthFreak <forthfreak@gmail.com> writes:
>>>>>> With a slight change to use PAD. This allows one to try different
>>>>>> circle sizes without need for re-compilation.
>>>>>
>>>>> I think it's better to use ALLOT.  PAD can be as small as 64 chars.
>>>>>
>>>>
>>>> But it almost never is, except on very limited embedded systems.
>>>> Perfectly ok to use PAD and declare a dependency on its length being at
>>>> least [n] bytes. Never handcuff yourself unnecessarily.
>>>
>>> Never mind size, PAD is CORE EXT and may not even exist.  Paul wins :)
>>>
>>> BTW PAD (if it exists) is 84 chars min.
>>
>> In practice, how many implementations don't support PAD? I suspect very
>> few! So, you have a dependency on PAD, and that it has a certain minimum
>> length. Is that likely to limit the usefulness of your code in any
>> meaningful way? All you need is to add a comment to your code like:
>>
>> \ Requires PAD with at least [x] bytes.
>>
>> I really don't understand the philosophy of programming extra complexity
>> to avoid something that is widely available and considered standard
>> practice. Making a permanent allocation for an array that is really
>> temporary in nature is not a "best practice".
>
> For all you know PAD is itself a permanent allocation.  Data space created
> with ALLOT can always be un-ALLOTed after the program is run.
>
> If a program is to be portable and run on as many systems and as possible,
> with as few dependencies as possible, and what's in CORE suffices or is
> in fact better - is that not "best practice" ?

It's really "best practice" to consider your objectives for this 
*particular* program. The objectives may be "to be portable and run on 
as many systems and as possible, with as few dependencies as possible," 
but may also be a more focused purpose, such as "to run on an embedded 
platform using minimal RAM," or perhaps "to serve as an example to 
people using mainstream Forths on PCs and workstations," or even "to 
show people using mainstream Forths on PCs what the simplest possible 
solution could be."

These are very different objectives. The last two, IMO, would be *less* 
useful if they adhered rigidly to CORE-only/minimum guarantees, since 
virtually no Forths are that limited, particularly on PCs. But it's 
certainly also an excellent practice to document your assumptions, such 
as the example comment I gave above.

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]

#27470

Elizabeth D Rather wrote:
> On 12/26/2013 3:33 PM, Ed wrote:
> > ...
> > For all you know PAD is itself a permanent allocation.  Data space created
> > with ALLOT can always be un-ALLOTed after the program is run.
> >
> > If a program is to be portable and run on as many systems and as possible,
> > with as few dependencies as possible, and what's in CORE suffices or is
> > in fact better - is that not "best practice" ?
>
> It's really "best practice" to consider your objectives for this
> *particular* program. The objectives may be "to be portable and run on
> as many systems and as possible, with as few dependencies as possible,"
> but may also be a more focused purpose, such as "to run on an embedded
> platform using minimal RAM," or perhaps "to serve as an example to
> people using mainstream Forths on PCs and workstations," or even "to
> show people using mainstream Forths on PCs what the simplest possible
> solution could be."
>
> These are very different objectives. The last two, IMO, would be *less*
> useful if they adhered rigidly to CORE-only/minimum guarantees, since
> virtually no Forths are that limited, particularly on PCs. But it's
> certainly also an excellent practice to document your assumptions, such
> as the example comment I gave above.

Let's look at the objectives for this particular program:

    Paul Rubin wrote:
    > ForthFreak <forthfreak@gmail.com> writes:
    > > With a slight change to use PAD. This allows one to try different
    > > circle sizes without need for re-compilation.
    >
    > I think it's better to use ALLOT.  PAD can be as small as 64 chars.

You need to store data of indeterminate size and you decide to use PAD
which the Standard does not require and is only guaranteed to be 84 chars.

I suggest this is not "best practice" but an application of PAD which goes
well beyond what the Standard intended.  That you have a system which
allows you to get away with it, is your good luck.  I, however, would prefer
to see a solution that befits the problem and doesn't resort to 'escape clauses'
to get the job done.  If Standard Forth is any good, surely such a solution
exists (?)

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

#27474

On Friday, December 27, 2013 7:46:12 AM UTC, Ed wrote:
> 
> I suggest this is not "best practice" but an application of PAD which goes
> well beyond what the Standard intended.  

Yep. I'd say that was a fair comment.

>That you have a system which allows you to get away with it, is your good 
>luck.  I, however, would prefer to see a solution that befits the problem and 
>doesn't resort to 'escape clauses' to get the job done.  If Standard Forth is 
>any good, surely such a solution exists (?)

Alrighty then. Here's my program again, this time, using HERE, and using variables rather than values.

(BTW: ForthFreak is me, in case anyone was wondering - I was just signed in under my YouTube ID and I didn't notice.)

forget #soldiers
variable #soldiers 
variable remain  #soldiers @ remain !
variable position 

: init ( --) 
    #soldiers @ 0 do 1  here i +  c!  loop 
    -1 position !  #soldiers @ remain ! ; 
    
: soldiers' ( -- addr) here position @ + ; 
    
: position++ ( --) 
    position @ 1+ #soldiers @ mod position ! ; 
    
: kill3rd ( --) 
    0 begin 
        position++  soldiers' c@ if 1+ then 
      dup 3 = until drop 
      0 soldiers' c!  position @ 1+ .  remain @ 1- remain ! ; 
    
: killThem ( --) init begin remain @ 0> while kill3rd repeat 
    cr ." Last man standing at position " position @ 1+ . ; 

: victims ( n -- ) #soldiers !  killThem ; 

No memory allocation/de-allocation required, and uses only CORE, as far as I know.

HERE is core, though, (sigh) the description is, as ever ambiguous.

6.1.1650 HERE ( -- addr ) CORE
addr is the data-space pointer.


Sigh... Is addr the address of the pointer (i.e. is HERE a variable that can be written to) or is addr the actual value of the current address pointer (more like a read-only VALUE).

Sigh.... FFS!

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

#27476

In article <c3d6cf12-045a-409c-9b43-ddb0539399f7@googlegroups.com>,
Mark Wills  <markrobertwills@yahoo.co.uk> wrote:
>On Friday, December 27, 2013 7:46:12 AM UTC, Ed wrote:
>>
>> I suggest this is not "best practice" but an application of PAD which goes
>> well beyond what the Standard intended.
>
>Yep. I'd say that was a fair comment.
>
>>That you have a system which allows you to get away with it, is your good
>>luck.  I, however, would prefer to see a solution that befits the problem and
>>doesn't resort to 'escape clauses' to get the job done.  If Standard Forth is
>>any good, surely such a solution exists (?)
>
>Alrighty then. Here's my program again, this time, using HERE, and using
>variables rather than values.
>
>(BTW: ForthFreak is me, in case anyone was wondering - I was just signed
>in under my YouTube ID and I didn't notice.)
>
>forget #soldiers
>variable #soldiers
>variable remain  #soldiers @ remain !
>variable position
>
>: init ( --)
>    #soldiers @ 0 do 1  here i +  c!  loop
>    -1 position !  #soldiers @ remain ! ;
>
>: soldiers' ( -- addr) here position @ + ;
>
>: position++ ( --)
>    position @ 1+ #soldiers @ mod position ! ;
>
>: kill3rd ( --)
>    0 begin
>        position++  soldiers' c@ if 1+ then
>      dup 3 = until drop
>      0 soldiers' c!  position @ 1+ .  remain @ 1- remain ! ;
>
>: killThem ( --) init begin remain @ 0> while kill3rd repeat
>    cr ." Last man standing at position " position @ 1+ . ;
>
>: victims ( n -- ) #soldiers !  killThem ;
>
>No memory allocation/de-allocation required, and uses only CORE, as far
>as I know.
>
>HERE is core, though, (sigh) the description is, as ever ambiguous.
>
>6.1.1650 HERE ( -- addr ) CORE
>addr is the data-space pointer.
>
>
>Sigh... Is addr the address of the pointer (i.e. is HERE a variable that
>can be written to) or is addr the actual value of the current address
>pointer (more like a read-only VALUE).
>
>Sigh.... FFS!

Actually using HERE without ALLOCate is a very bad solution.
As soon as you type in, on some Forth's parsed words are placed
there. Classic FIG (and ciforth) uses buffers for numeric output
there, and the standard is carefully formulated to allow both
practices.

OTOH PAD entitles you to a buffer, and the size is guaranteed to
be *at least* 82 chars. In practice you can easily use a million
bytes at HERE in 32 bit Forths like gforth and ciforth (I didn't
check other implementations.)

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]

#27477

On Friday, December 27, 2013 2:16:44 PM UTC+1, Albert van der Horst wrote:
> In article <c3d6cf12-045a-409c-9b43-ddb0539399f7@googlegroups.com>,
[..]
> In practice you can easily use a million
> bytes at HERE in 32 bit Forths like gforth and ciforth (I didn't
> check other implementations.)
[..]
( There is a Standard way )
FORTH> UNUSED . 63705936  ok

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

#27478

In article <67320c29-326e-418f-896c-b84578fad5a4@googlegroups.com>,
 <mhx@iae.nl> wrote:
>On Friday, December 27, 2013 2:16:44 PM UTC+1, Albert van der Horst wrote:
>> In article <c3d6cf12-045a-409c-9b43-ddb0539399f7@googlegroups.com>,
>[..]
>> In practice you can easily use a million
>> bytes at HERE in 32 bit Forths like gforth and ciforth (I didn't
>> check other implementations.)
>[..]
>( There is a Standard way )
>FORTH> UNUSED . 63705936  ok
>

I recently upgraded my system to 8 Gbyte, and used -g to grow
my forth accordingly. I can now generate tables to calculate
the Mertens function up to 10^11.  :-)

albert@cherry:~$ lina64be -a
WANT UNUSED WANT MARK-TIME
 OK
UNUSED .
8389545880  OK
MARK-TIME HERE UNUSED 100 - ERASE ELAPSED
 OK
.mS
 19244.587mS  OK

BYE

[ on ciforth's PAD is in fact about as large. Only it screens off the part
of memory that is not available to you. ]

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]

#27498

Albert van der Horst wrote:
> ...
> Actually using HERE without ALLOCate is a very bad solution.
> As soon as you type in, on some Forth's parsed words are placed
> there. Classic FIG (and ciforth) uses buffers for numeric output
> there, and the standard is carefully formulated to allow both
> practices.
>
> OTOH PAD entitles you to a buffer, and the size is guaranteed to
> be *at least* 82 chars. In practice you can easily use a million
> bytes at HERE in 32 bit Forths like gforth and ciforth (I didn't
> check other implementations.)

The classic memory model is still used so one might expect  /PAD to return
a value in the order of UNUSED.  But not so.  As far as a Standard Program
is aware, the size of PAD is:

SwiftForth demo ... 256
GForth ... 84
DX-Forth ... 256

VFX and Win32F put PAD elsewhere so I list them separately.  I assume
they did this so apps could use HERE without fear of overwriting anything.
OTOH this would limit PAD to a fixed size.

Old VFX demo ... 1792
Win32F ... 260

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

#27501

In article <l9ov5m$72d$1@speranza.aioe.org>, Ed <invalid@invalid.com> wrote:
>Albert van der Horst wrote:
>> ...
>> Actually using HERE without ALLOCate is a very bad solution.
>> As soon as you type in, on some Forth's parsed words are placed
>> there. Classic FIG (and ciforth) uses buffers for numeric output
>> there, and the standard is carefully formulated to allow both
>> practices.
>>
>> OTOH PAD entitles you to a buffer, and the size is guaranteed to
>> be *at least* 82 chars. In practice you can easily use a million
>> bytes at HERE in 32 bit Forths like gforth and ciforth (I didn't
>> check other implementations.)
>
>The classic memory model is still used so one might expect  /PAD to return
>a value in the order of UNUSED.  But not so.  As far as a Standard Program
>is aware, the size of PAD is:
>
>SwiftForth demo ... 256
>GForth ... 84

Where did you look?
gForth tries to comply with the documentation requirements of ISO.
So you will find the following at the exact place where you ought to
look:
"
size of the scratch area returned by `PAD':
     The remainder of dictionary space. `unused pad here - - .'.
"

albert@cherry:~$ gforth -m 1G
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
unused . 1073384498  ok

You forgive me that I don't subtract the space for the output buffer.

This is *documented*, so it is an *entitlement*.

>DX-Forth ... 256
>
>VFX and Win32F put PAD elsewhere so I list them separately.  I assume
>they did this so apps could use HERE without fear of overwriting anything.
>OTOH this would limit PAD to a fixed size.
>
>Old VFX demo ... 1792
>Win32F ... 260
>
>
>
>
>
-- 
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]

#27504

Albert van der Horst wrote:
> In article <l9ov5m$72d$1@speranza.aioe.org>, Ed <invalid@invalid.com> wrote:
> > ...
> >SwiftForth demo ... 256
> >GForth ... 84
>
> Where did you look?
> gForth tries to comply with the documentation requirements of ISO.
> So you will find the following at the exact place where you ought to
> look:
> "
> size of the scratch area returned by `PAD':
>      The remainder of dictionary space. `unused pad here - - .'.
> "

Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
s" /PAD" environment? drop u. 84  ok

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

#27494

Mark Wills wrote:
> ...
> HERE is core, though, (sigh) the description is, as ever ambiguous.
>
> 6.1.1650 HERE ( -- addr ) CORE
> addr is the data-space pointer.
>
>
> Sigh... Is addr the address of the pointer (i.e. is HERE a variable that can be written to)
> or is addr the actual value of the current address pointer (more like a read-only VALUE).
>
> Sigh.... FFS!

To understand the ANS definition, the reader is expected to have read:

    2.1 Definitions of terms
    ...
    data-space pointer:

    The address of the next available data space location, i.e., the value returned by HERE.

The phrase is used many times throughout the text.  I can understand your confusion ...
and their problem.

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

#27472

On Friday, December 27, 2013 1:33:16 AM UTC, Ed wrote:
>
> <snip>Data space created with ALLOT can always be un-ALLOTed after the
> program is run.

Really? How? As far as I know, there is no standard way to get that memory back. ALLOT moves the current compilation address, and then the program is compiled after the alloted data. That data space is gone, as far as the rest of the system is concerned.

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

#27473

Ah... I guess a negative ALLOT would actually allow you to reclaim that memory. Hmmm okay.

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

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

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

csiph-web