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

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

Array of Constants in Mecrisp

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

Contents

  Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-10 11:06 -0400
    Array of Constants in Mecrisp Mark Wills <markwills1970@gmail.com> - 2015-05-10 09:02 -0700
      Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-10 15:50 -0400
        Re: Array of Constants in Mecrisp Mark Wills <markwills1970@gmail.com> - 2015-05-11 00:38 -0700
        Re: Array of Constants in Mecrisp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-05-11 12:10 +0200
          Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-11 11:24 -0400
            Re: Array of Constants in Mecrisp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-05-12 13:03 +0200
          Re: Array of Constants in Mecrisp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-11 23:19 +0000
            Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-11 20:47 -0400
              Re: Array of Constants in Mecrisp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-12 17:05 +0000
            Re: Array of Constants in Mecrisp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-05-12 12:49 +0200
          Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-14 13:00 -0400
            Re: Array of Constants in Mecrisp "Alex McDonald" <blog@rivadpm.com> - 2015-05-14 18:04 +0100
              Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-14 13:20 -0400
                Re: Array of Constants in Mecrisp "Alex McDonald" <blog@rivadpm.com> - 2015-05-14 18:46 +0100
                Re: Array of Constants in Mecrisp Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-14 20:42 +0200
                  Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-15 11:25 -0400
                Re: Array of Constants in Mecrisp "Elizabeth D. Rather" <erather@forth.com> - 2015-05-14 09:11 -1000
                Re: Array of Constants in Mecrisp anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-15 07:26 +0000
                  Re: Array of Constants in Mecrisp "Elizabeth D. Rather" <erather@forth.com> - 2015-05-14 22:30 -1000
                    Re: Array of Constants in Mecrisp anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-15 10:03 +0000
                      Re: Array of Constants in Mecrisp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-15 11:05 +0000
                        Re: Array of Constants in Mecrisp anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-15 12:51 +0000
                          Re: Array of Constants in Mecrisp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-15 15:40 +0000
                            Re: Array of Constants in Mecrisp anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-16 13:40 +0000
                              Re: Array of Constants in Mecrisp "Elizabeth D. Rather" <erather@forth.com> - 2015-05-16 11:25 -1000
                      Re: Array of Constants in Mecrisp "Elizabeth D. Rather" <erather@forth.com> - 2015-05-15 09:28 -1000
                Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-15 11:31 -0400
                  Re: Array of Constants in Mecrisp "Elizabeth D. Rather" <erather@forth.com> - 2015-05-15 09:31 -1000
                    Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-16 10:00 -0400
                      Re: Array of Constants in Mecrisp anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-16 16:12 +0000
                        Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-16 13:58 -0400
                          Re: Array of Constants in Mecrisp anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-16 18:03 +0000
                            Re: Array of Constants in Mecrisp Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-18 00:36 +0200
                              Re: Array of Constants in Mecrisp Lars Brinkhoff <lars.spam@nocrew.org> - 2015-05-18 08:37 +0200
                                Re: Array of Constants in Mecrisp Coos Haak <chforth@hccnet.nl> - 2015-05-18 12:55 +0200
                                  Re: Array of Constants in Mecrisp Lars Brinkhoff <lars.spam@nocrew.org> - 2015-05-18 13:44 +0200
                                    Re: Array of Constants in Mecrisp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-19 00:17 +0000
                        Re: Array of Constants in Mecrisp "Elizabeth D. Rather" <erather@forth.com> - 2015-05-16 11:36 -1000
                      Re: Array of Constants in Mecrisp "Elizabeth D. Rather" <erather@forth.com> - 2015-05-16 11:27 -1000
              Re: Array of Constants in Mecrisp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-15 10:48 +0000
    Re: Array of Constants in Mecrisp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-05-11 12:06 +0200
      Re: Array of Constants in Mecrisp Mark Wills <markwills1970@gmail.com> - 2015-05-11 04:48 -0700
        Re: Array of Constants in Mecrisp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-05-12 12:39 +0200
          Re: Array of Constants in Mecrisp foxaudioresearch@gmail.com - 2015-05-12 16:29 -0700
      Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-14 13:05 -0400
        Re: Array of Constants in Mecrisp Coos Haak <chforth@hccnet.nl> - 2015-05-14 22:21 +0200
          Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-15 11:27 -0400

Page 1 of 3  [1] 2 3  Next page →

#38936 — Array of Constants in Mecrisp

I need a table of constants, I prefer not to use a defining word.  I 
just want a simple way to make an array of constant data.  Most of the 
examples I find use defining words and create.  The problem is I don't 
think Mecrisp has a standard create and I don't understand the 
documentation on what it does.  The comments seem to say use <builds 
instead, but I am much less clear on what that does since it is no 
longer in ANS forth.

I've tried testing some ideas and seem to have whacked the target board 
so I'm going to have to reflash it.  I can't test this in another Forth 
because <builds is no longer supported... at least in Win32Forth.

<sigh>  I'm getting rather frustrated.  Maybe I need to go out in the 
kayak...

-- 

Rick

[toc] | [next] | [standalone]

#38941

What's wrong with comma?

Is it fig forth?

If it's running on a microcontroller then you need to determine if you want to put your data in ram or flash. There may be different words or switches to select the appropriate behaviours. 

Try

variable array 0, 2 , 4 , 6 , 8 ,

Do you get an underflow error?  If so you need

0 variable array 2 , 4 , 6 , 8 ,

Then try 

array 2 cells + @ .

You should get 2 echoed back. 

HTH

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

#38950

On 5/10/2015 12:02 PM, Mark Wills wrote:
> What's wrong with comma?
>
> Is it fig forth?
>
> If it's running on a microcontroller then you need to determine if you want to put your data in ram or flash. There may be different words or switches to select the appropriate behaviours.

That's already taken care of with compiletoram and compiletoflash.


> Try
>
> variable array 0, 2 , 4 , 6 , 8 ,
>
> Do you get an underflow error?  If so you need
>
> 0 variable array 2 , 4 , 6 , 8 ,
>
> Then try
>
> array 2 cells + @ .
>
> You should get 2 echoed back.

It would be nice if the address calculation were done in the array word. 
  Here is what I can get to work using a defining word.  I thought it 
would be more complicated, but this isn't so bad.  Still, it just seems 
like I should be able to do everything in the constant array definition 
rather than using a defining word.

compiletoram

: charconstarray <builds does> + c@ ;

charconstarray arraytest
   $1E c, $08 c, $1D c, $19 c, $0B c, $13 c, $17 c, $18 c, $1F c, $1B c,

There is no bounds checking, but this is fine for now.  Some time back 
someone gave me some pointers on constructing arrays, but everything I 
did with that was more complex than I need now and uses create which I 
don't think I can use in Mecrisp.

In the above code, is <builds necessary?  Could it be omitted or does it 
muck with the state or something that is needed with does> ?

-- 

Rick

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

#38960

On Sunday, 10 May 2015 20:50:28 UTC+1, rickman  wrote:
> 
> compiletoram
> 
> : charconstarray <builds does> + c@ ;
> 
> charconstarray arraytest
>    $1E c, $08 c, $1D c, $19 c, $0B c, $13 c, $17 c, $18 c, $1F c, $1B c,
> 
> In the above code, is <builds necessary?  Could it be omitted or does it 
> muck with the state or something that is needed with does> ?
> 
> -- 
> 
> Rick

If you want to be able to create named arrays simply, then yes.
If you just have one, or maybe a couple you could get by without it:

variable consts 2 , 4 , 6 , 8 , 10 ,

: @consts ( index -- n )
  cells consts + @ ;

: !consts ( val index -- )
  cells consts + ! ;

Note: The above (obviously) are cell based, rather than char/byte
based, but you get the idea... Just create accessors (is that a real
English word? Dunno!) for each array. It's more work than builds...does
but won't be any slower performance wise.

M

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

#38962

> compiletoram
> 
> : charconstarray <builds does> + c@ ;
> 
> charconstarray arraytest
>   $1E c, $08 c, $1D c, $19 c, $0B c, $13 c, $17 c, $18 c, $1F c, $1B c,
> In the above code, is <builds necessary?  Could it be omitted or does it 
> muck with the state or something that is needed with does> ?
> 

<builds does> is necessary because the standard action of create cannot be overwritten when compiling into flash. So create has standard action, <builds has no action.

Matthias

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

#38968

On 5/11/2015 6:10 AM, Matthias Koch wrote:
>> compiletoram
>>
>> : charconstarray <builds does> + c@ ;
>>
>> charconstarray arraytest
>>   $1E c, $08 c, $1D c, $19 c, $0B c, $13 c, $17 c, $18 c, $1F c, $1B c,
>> In the above code, is <builds necessary?  Could it be omitted or does
>> it muck with the state or something that is needed with does> ?
>>
>
> <builds does> is necessary because the standard action of create cannot
> be overwritten when compiling into flash. So create has standard action,
> <builds has no action.

Unfortunately I don't have enough experience with create to understand 
this issue.  Here is the code I am using.  In the end I decided to add 
bounds checking because array index errors require me to manually cycle 
power on the target board.  lol

: within  ( n lo hi+1 -- flag )  OVER -  >R  -  R> U< ;

\ n is size of array, word defined reads indexed constant data with 
range check
: charconstarray: ( n1 -- ) <builds ,
                   ( n2 -- ) does> 2dup c@ 0 swap within
                   if cell+ + c@ else cr ." *** Array subscript error 
*** " drop . cr then ;

10 charconstarray: arraytest
   $1E c, $08 c, $1D c, $19 c, $0B c, $13 c, $17 c, $18 c, $1F c, $1B c,

I wanted to use a char to store n1, but it appears does> aligns, so a 
cell is used anyway.

I assume all the code for charconstarray: is stored in that definition. 
  How does arraytest use it?  Where is the dictionary structure defined? 
  Does does> create a link from arraytest back to the code after does>? 
  I'm trying to figure if there is an easy way to print the name of the 
array word in the error message.

The comments in the Mecrisp Forth code have a lot of English and I have 
been able to translate the German mostly.  But in the assembly code 
there is a lot more German.  You are making me work, lol.  :)

At least I am debugging my code finally.

-- 

Rick

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

#39015

Just load the disassembler from the commons folder and SEE some freshly written <builds and <builds does> definitions.

Create in Mecrisp-Stellaris is just : create <builds does> ;

Note that variables are initialised "42 variable answer", same for "3,14159 2variable pi" (special: comma instead of dot in numbers converts as s31.32 fixpoint number), this value is reloaded after Reset, and neither regular variables nor constants nor buffer: make use of the <builds does> mechanism. Don't forget to put flags like immediate inside of the definition when you wish to compiletoflash.

Matthias

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

#38996

In article <mipv64$r80$2@newsserver.rrzn.uni-hannover.de>,
Matthias Koch  <matthias.koch@hot.uni-hannover.de> wrote:
>> compiletoram
>>
>> : charconstarray <builds does> + c@ ;
>>
>> charconstarray arraytest
>>   $1E c, $08 c, $1D c, $19 c, $0B c, $13 c, $17 c, $18 c, $1F c, $1B c,
>> In the above code, is <builds necessary?  Could it be omitted or does it
>> muck with the state or something that is needed with does> ?
>>
>
><builds does> is necessary because the standard action of create cannot
>be overwritten when compiling into flash. So create has standard action,
><builds has no action.

This is a matter of implementation, not imposed by the separation between
ram and flash.

noforth has the following code as part of a demonstration by Albert
Nijhof for playing Beethoven songs (sorry, pieces).

\ ----- compile (define) a tune in ROM ----------------
: DOTUNE: does> play ;
: TUNE: create dotune:
   begin bl-word count
         2dup upper
         over c@                \ adr count first-ch
         dup ch ; <>
   while >r
        dup 1 =
        if   ch \ r@ =  if postpone \   else            \ forth comment \
             ch ( r@ =  if postpone (   else            \ forth comment (
             r@ c,                      then then       \ compile character
        else ch \ r@ =   if   ch | c,   else            \ bar number
             ch ( r@ =   if             else            \ skip string
             2dup m,                    then then       \ compile string
        then
        rdrop 2drop
   repeat c, align 2drop ;

Not that I understand the code in full, but it should be clear that CREATE & DOES>
are used in a regular way. The word ROM refers to the fact that the tune
is stored in ROM.

There remain a few caveats, that can be found in the documentation of
noforth.

>
>Matthias

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]

#39001

On 5/11/2015 7:19 PM, Albert van der Horst wrote:
> In article <mipv64$r80$2@newsserver.rrzn.uni-hannover.de>,
> Matthias Koch  <matthias.koch@hot.uni-hannover.de> wrote:
>>> compiletoram
>>>
>>> : charconstarray <builds does> + c@ ;
>>>
>>> charconstarray arraytest
>>>    $1E c, $08 c, $1D c, $19 c, $0B c, $13 c, $17 c, $18 c, $1F c, $1B c,
>>> In the above code, is <builds necessary?  Could it be omitted or does it
>>> muck with the state or something that is needed with does> ?
>>>
>>
>> <builds does> is necessary because the standard action of create cannot
>> be overwritten when compiling into flash. So create has standard action,
>> <builds has no action.
>
> This is a matter of implementation, not imposed by the separation between
> ram and flash.
>
> noforth has the following code as part of a demonstration by Albert
> Nijhof for playing Beethoven songs (sorry, pieces).
>
> \ ----- compile (define) a tune in ROM ----------------
> : DOTUNE: does> play ;
> : TUNE: create dotune:
>     begin bl-word count
>           2dup upper
>           over c@                \ adr count first-ch
>           dup ch ; <>
>     while >r
>          dup 1 =
>          if   ch \ r@ =  if postpone \   else            \ forth comment \
>               ch ( r@ =  if postpone (   else            \ forth comment (
>               r@ c,                      then then       \ compile character
>          else ch \ r@ =   if   ch | c,   else            \ bar number
>               ch ( r@ =   if             else            \ skip string
>               2dup m,                    then then       \ compile string
>          then
>          rdrop 2drop
>     repeat c, align 2drop ;
>
> Not that I understand the code in full, but it should be clear that CREATE & DOES>
> are used in a regular way. The word ROM refers to the fact that the tune
> is stored in ROM.
>
> There remain a few caveats, that can be found in the documentation of
> noforth.

Thanks for the attempt to help, but this is still over my head. 
Unfortunately most of the guts of Mecrisp are written in assembly with 
lots of German comments, so it will be a struggle to figure it all out. 
  Once I finish with my current project (shouldn't be too many more 
days) I will come back to this since I think it is important.

-- 

Rick

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

#39032

In article <mirih2$muf$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>On 5/11/2015 7:19 PM, Albert van der Horst wrote:
>> In article <mipv64$r80$2@newsserver.rrzn.uni-hannover.de>,
>> Matthias Koch  <matthias.koch@hot.uni-hannover.de> wrote:
>>>> compiletoram
>>>>
>>>> : charconstarray <builds does> + c@ ;
>>>>
>>>> charconstarray arraytest
>>>>    $1E c, $08 c, $1D c, $19 c, $0B c, $13 c, $17 c, $18 c, $1F c, $1B c,
>>>> In the above code, is <builds necessary?  Could it be omitted or does it
>>>> muck with the state or something that is needed with does> ?
>>>>
>>>
>>> <builds does> is necessary because the standard action of create cannot
>>> be overwritten when compiling into flash. So create has standard action,
>>> <builds has no action.
>>
>> This is a matter of implementation, not imposed by the separation between
>> ram and flash.
>>
>> noforth has the following code as part of a demonstration by Albert
>> Nijhof for playing Beethoven songs (sorry, pieces).
>>
>> \ ----- compile (define) a tune in ROM ----------------
>> : DOTUNE: does> play ;
>> : TUNE: create dotune:
>>     begin bl-word count
>>           2dup upper
>>           over c@                \ adr count first-ch
>>           dup ch ; <>
>>     while >r
>>          dup 1 =
>>          if   ch \ r@ =  if postpone \   else            \ forth comment \
>>               ch ( r@ =  if postpone (   else            \ forth comment (
>>               r@ c,                      then then       \ compile character
>>          else ch \ r@ =   if   ch | c,   else            \ bar number
>>               ch ( r@ =   if             else            \ skip string
>>               2dup m,                    then then       \ compile string
>>          then
>>          rdrop 2drop
>>     repeat c, align 2drop ;
>>
>> Not that I understand the code in full, but it should be clear that CREATE & DOES>
>> are used in a regular way. The word ROM refers to the fact that the tune
>> is stored in ROM.
>>
>> There remain a few caveats, that can be found in the documentation of
>> noforth.
>
>Thanks for the attempt to help, but this is still over my head.
>Unfortunately most of the guts of Mecrisp are written in assembly with
>lots of German comments, so it will be a struggle to figure it all out.
>  Once I finish with my current project (shouldn't be too many more
>days) I will come back to this since I think it is important.

My intention was more to inspire the Mecrisp implementors to find a
solution that makes it easier for the likes of you.
Certainly digging into the guts of Mecrisp if you can't understand the
comment properly is not the way to go.

>
>--
>
>Rick

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]

#39014

>> <builds does> is necessary because the standard action of create cannot
>> be overwritten when compiling into flash. So create has standard action,
>> <builds has no action.
> 
> This is a matter of implementation, not imposed by the separation between
> ram and flash.

Hi Albert,

I know, noForth is using a clever trick to accomplish this... Well done.

Camelforth suffers from the same issue.

Matthias

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

#39113

On 5/11/2015 6:10 AM, Matthias Koch wrote:
>> compiletoram
>>
>> : charconstarray <builds does> + c@ ;
>>
>> charconstarray arraytest
>>   $1E c, $08 c, $1D c, $19 c, $0B c, $13 c, $17 c, $18 c, $1F c, $1B c,
>> In the above code, is <builds necessary?  Could it be omitted or does
>> it muck with the state or something that is needed with does> ?
>>
>
> <builds does> is necessary because the standard action of create cannot
> be overwritten when compiling into flash. So create has standard action,
> <builds has no action.

So what *is* the standard action of create?  Does> puts the data field 
address on the stack, right?

-- 

Rick

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

#39114

on 14/05/2015 18:00:34, rickman wrote:
> On 5/11/2015 6:10 AM, Matthias Koch wrote:
>>> compiletoram
>>>
>>> : charconstarray <builds does> + c@ ;
>>>
>>> charconstarray arraytest
>>>   $1E c, $08 c, $1D c, $19 c, $0B c, $13 c, $17 c, $18 c, $1F c, $1B c,
>>> In the above code, is <builds necessary?  Could it be omitted or does
>>> it muck with the state or something that is needed with does> ?
>>>
>>
>> <builds does> is necessary because the standard action of create cannot
>> be overwritten when compiling into flash. So create has standard action,
>> <builds has no action.
> 
> So what *is* the standard action of create? Does> puts the data field
> address on the stack, right?
> 

CREATE puts the data field address on the stack. DOES> adds to that
behaviour by executing the code that follows it.

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

#39116

On 5/14/2015 1:04 PM, Alex McDonald wrote:
> on 14/05/2015 18:00:34, rickman wrote:
>> On 5/11/2015 6:10 AM, Matthias Koch wrote:
>>>> compiletoram
>>>>
>>>> : charconstarray <builds does> + c@ ;
>>>>
>>>> charconstarray arraytest
>>>>    $1E c, $08 c, $1D c, $19 c, $0B c, $13 c, $17 c, $18 c, $1F c, $1B c,
>>>> In the above code, is <builds necessary?  Could it be omitted or does
>>>> it muck with the state or something that is needed with does> ?
>>>>
>>>
>>> <builds does> is necessary because the standard action of create cannot
>>> be overwritten when compiling into flash. So create has standard action,
>>> <builds has no action.
>>
>> So what *is* the standard action of create? Does> puts the data field
>> address on the stack, right?
>>
>
> CREATE puts the data field address on the stack. DOES> adds to that
> behaviour by executing the code that follows it.

Can you explain what is meant by

DOES> “does” CORE
Run-time: ( –– ) ( R: nest-sys 1 –– )
Replace the execution semantics of the most recent definition, referred 
to as name, with the name execution semantics given below.

"Replace" seems to be what Matthais is talking about causing a problem 
in flash.  But if CREATE puts the DFA on the stack and DOES> appends to 
that, what is being replaced?

BTW, what does "Run-time" mean?  The only mention of it in the standard 
is, 'The terms “initiation semantics” and “run-time semantics” refer to 
definition fragments, and have meaning only within the individual 
glossary entries where they appear.'  I guess I don't get how this is 
different from execution...?

-- 

Rick

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

#39117

on 14/05/2015 18:20:26, rickman wrote:
> On 5/14/2015 1:04 PM, Alex McDonald wrote:
>> on 14/05/2015 18:00:34, rickman wrote:
>>> On 5/11/2015 6:10 AM, Matthias Koch wrote:
>>>>> compiletoram
>>>>>
>>>>> : charconstarray <builds does> + c@ ;
>>>>>
>>>>> charconstarray arraytest
>>>>>    $1E c, $08 c, $1D c, $19 c, $0B c, $13 c, $17 c, $18 c, $1F c, $1B c,
>>>>> In the above code, is <builds necessary?  Could it be omitted or does
>>>>> it muck with the state or something that is needed with does> ?
>>>>>
>>>>
>>>> <builds does> is necessary because the standard action of create cannot
>>>> be overwritten when compiling into flash. So create has standard action,
>>>> <builds has no action.
>>>
>>> So what *is* the standard action of create? Does> puts the data field
>>> address on the stack, right?
>>>
>>
>> CREATE puts the data field address on the stack. DOES> adds to that
>> behaviour by executing the code that follows it.
> 
> Can you explain what is meant by
> 
> DOES> “does” CORE
> Run-time: ( –– ) ( R: nest-sys 1 –– )
> Replace the execution semantics of the most recent definition,
> referred to as name, with the name execution semantics given below.
> 
> "Replace" seems to be what Matthais is talking about causing a problem
> in flash. But if CREATE puts the DFA on the stack and DOES> appends to
> that, what is being replaced?
> 
> BTW, what does "Run-time" mean? The only mention of it in the standard
> is, 'The terms “initiation semantics” and “run-time semantics” refer
> to definition fragments, and have meaning only within the individual
> glossary entries where they appear.'  I guess I don't get how this is
> different from execution...?
> 
> --
> 
> Rick
> 

: DEFINEVAR CREATE , ;
10 DEFINEVAR VAR
VAR . ( prints address)
 
will have the action [ ' VAR >BODY ] LITERAL (that is, the address of the
cell that contains 10) when VAR is executed.

: DEFINEVAR CREATE , DOES> @ 2 + ;
10 DEFINEVAR VAR
VAR ( prints 12)

now has the action [ ' VAR >BODY ] LITERAL @ 2 + when VAR is executed. 

While compiling VAR, DOES> has modified the action of VAR, and this may
requiring replacing the first action with the second. It's important to
work out what is being executed when. The CREATE to DOES> is executed
when DEFINEVAR is executed. The bit after DOES> is executed when VAR is
executed.

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

#39121

rickman wrote:

> Can you explain what is meant by
> 
> DOES> “does” CORE
> Run-time: ( –– ) ( R: nest-sys 1 –– )
> Replace the execution semantics of the most recent definition, referred
> to as name, with the name execution semantics given below.

CREATE creates a word header, and the header code field first contains a 
"dovar" pointer, which, when executed, will put the address onto the stack.

> "Replace" seems to be what Matthais is talking about causing a problem
> in flash.  But if CREATE puts the DFA on the stack and DOES> appends to
> that, what is being replaced?

DOES> replaces this dovar field with the code following DOES>.

On a flash system, you can only write once (or at least only change a 1 bit 
to 0).  This means that <BUILDS creates a header with a virgin (not yet 
useable) code field.  This virgin code field can then be replaced by DOES>, 
once.

> BTW, what does "Run-time" mean?  The only mention of it in the standard
> is, 'The terms “initiation semantics” and “run-time semantics” refer to
> definition fragments, and have meaning only within the individual
> glossary entries where they appear.'  I guess I don't get how this is
> different from execution...?

run-time is the semantics added by compile-time.  That's by default 
execution semantics, but sometimes, it's not the default, so it's specified.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#39145

On 5/14/2015 2:42 PM, Bernd Paysan wrote:
> rickman wrote:
>
>> Can you explain what is meant by
>>
>> DOES> “does” CORE
>> Run-time: ( –– ) ( R: nest-sys 1 –– )
>> Replace the execution semantics of the most recent definition, referred
>> to as name, with the name execution semantics given below.
>
> CREATE creates a word header, and the header code field first contains a
> "dovar" pointer, which, when executed, will put the address onto the stack.
>
>> "Replace" seems to be what Matthais is talking about causing a problem
>> in flash.  But if CREATE puts the DFA on the stack and DOES> appends to
>> that, what is being replaced?
>
> DOES> replaces this dovar field with the code following DOES>.
>
> On a flash system, you can only write once (or at least only change a 1 bit
> to 0).  This means that <BUILDS creates a header with a virgin (not yet
> useable) code field.  This virgin code field can then be replaced by DOES>,
> once.
>
>> BTW, what does "Run-time" mean?  The only mention of it in the standard
>> is, 'The terms “initiation semantics” and “run-time semantics” refer to
>> definition fragments, and have meaning only within the individual
>> glossary entries where they appear.'  I guess I don't get how this is
>> different from execution...?
>
> run-time is the semantics added by compile-time.  That's by default
> execution semantics, but sometimes, it's not the default, so it's specified.

Ok, that's more clear.  Thanks.

-- 

Rick

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

#39124

On 5/14/15 7:20 AM, rickman wrote:
> On 5/14/2015 1:04 PM, Alex McDonald wrote:
>> on 14/05/2015 18:00:34, rickman wrote:
>>> On 5/11/2015 6:10 AM, Matthias Koch wrote:
>>>>> compiletoram
>>>>>
>>>>> : charconstarray <builds does> + c@ ;
>>>>>
>>>>> charconstarray arraytest
>>>>>    $1E c, $08 c, $1D c, $19 c, $0B c, $13 c, $17 c, $18 c, $1F c,
>>>>> $1B c,
>>>>> In the above code, is <builds necessary?  Could it be omitted or does
>>>>> it muck with the state or something that is needed with does> ?
>>>>>
>>>>
>>>> <builds does> is necessary because the standard action of create cannot
>>>> be overwritten when compiling into flash. So create has standard
>>>> action,
>>>> <builds has no action.
>>>
>>> So what *is* the standard action of create? Does> puts the data field
>>> address on the stack, right?
>>>
>>
>> CREATE puts the data field address on the stack. DOES> adds to that
>> behaviour by executing the code that follows it.

Not exactly. DOES> *replaces* the behavior of putting the data field 
address on the stack by code that starts with that and may do additional 
stuff. In conventional implementations there is only one "action" address.

> Can you explain what is meant by
>
> DOES> “does” CORE
> Run-time: ( –– ) ( R: nest-sys 1 –– )
> Replace the execution semantics of the most recent definition, referred
> to as name, with the name execution semantics given below.
>
> "Replace" seems to be what Matthais is talking about causing a problem
> in flash.  But if CREATE puts the DFA on the stack and DOES> appends to
> that, what is being replaced?

As noted above, DOES> doesn't append, it replaces. Delivery of the 
address doesn't necessarily require a pointer cell; it can be done, for 
example, by a JSR to the code for the DOES> behavior.

> BTW, what does "Run-time" mean?  The only mention of it in the standard
> is, 'The terms “initiation semantics” and “run-time semantics” refer to
> definition fragments, and have meaning only within the individual
> glossary entries where they appear.'  I guess I don't get how this is
> different from execution...?

Consider these 2 definitions:

: VAR ( -- )  CREATE DOES> ( -- a ) ;
VAR STUFF

: ARRAY ( n -- )  CREATE CELLS ALLOT
    DOES> ( i -- a )  SWAP CELLS + ;  \ Returns the ith address
100 ARRAY DATA
5 DATA \ Returns addr of 5th cell in DATA

"Run-time semantics" refers to code that is executed when a word defined 
by a defining word is executed. In both cases, there is "initiation 
semantics" consisting of pushing the address of the data field of the 
child (or instance) word (STUFF or DATA) on the stack. VAR adds no 
additional semantics, but ARRAY does. The term "run-time semantics" 
refers to the instance behavior of each of these words, which includes 
the initiation semantics plus whatever is added (if anything).

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]

#39131

rickman <gnuarm@gmail.com> writes:
>Can you explain what is meant by
>
>DOES> “does” CORE
>Run-time: ( –– ) ( R: nest-sys 1 –– )
>Replace the execution semantics of the most recent definition, referred 
>to as name, with the name execution semantics given below.
>
>"Replace" seems to be what Matthais is talking about causing a problem 
>in flash.

Yes.

>But if CREATE puts the DFA on the stack and DOES> appends to 
>that, what is being replaced?

What actually happens is that, in, e.g., a threaded-code
implementation, the code field of the created word originally contains
a code address that is called docreate in fig-Forth, and that pushes
the PFA on the stack.  DOES> replaces that with a code address that
pushes the PFA and then calls the code after the DOES>.  And if you
call another DOES> while the word is still the most recent definition,
the earlier DOES> code address is replaced by the code address
belonging to the new DOES>.  E.g.:

: doesa does> drop ." a" ;
: doesb does> drop ." b" ;
create foo
doesa
foo \ prints "a"
doesb
foo \ prints "b"
doesa
foo \ prints "a" again

And this is the problem if the code field is in flash: overwriting is
not easily possible.  Native-code compilers also implement this with
an overwritable field and have the same problem.

Andrew Haley suggested replacing CREATE...DOES> with a word that does
both steps at once instead of this "replacing" stuff, e.g., something
like:

: doesa1 drop ." a" ;
' doesa1 create-does> foo
foo \ prints a
\ no replacements possible

That seems to be the best solution to me.  I am sure that you all can
come up with better names than CREATE-DOES> (but cannot find consensus
on a single one:-).

>BTW, what does "Run-time" mean?  The only mention of it in the standard 
>is, 'The terms “initiation semantics” and “run-time semantics” refer to 
>definition fragments, and have meaning only within the individual 
>glossary entries where they appear.'

E.g., the specification of DOES> contains:

|Compilation ( C: colon-sys1 -- colon-sys2 ) 
|  Append the run-time semantics below to the current definition.
|
|Run-time ( -- ) ( R: nest-sys1 -- )
|  Replace the execution semantics of the most recent definition, ...

So the reference to "run-time semantics" in the compilation semantics
of DOES> refers to the part specified in the "Run-Time" section.

>I guess I don't get how this is 
>different from execution...?

From the point of view of the specification, the run-time semantics of
certain words is private to that word, while the execution semantics
can be accessed from outside.

From an implementation point of view, in threaded-code systems the
run-time semantics is usually implemented through a helper word,
possibly with some additional inline argument.  E.g., IIRC the helper
word for DOES> is called (DOES>) in fig-Forth, the helper word for IF
is called 0BRANCH (and that takes the (relative) target address as
inline argument, and the helper word for LITERAL is called LIT and
takes n as inline argument.

In native-code Forths, "appending the run-time semantics given below"
may just result in a change how code is generated.  E.g., LITERAL +
may result in a register-immediate add instead of a register-register
add.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#39132

On 5/14/15 9:26 PM, Anton Ertl wrote:
> And this is the problem if the code field is in flash: overwriting is
> not easily possible.  Native-code compilers also implement this with
> an overwritable field and have the same problem.

But interactive cross-compilers have no problem, because they generate a 
target image in host (e.g. PC) RAM, download it, and then establish the 
interactive link to it.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web