On Friday, September 24, 2021 at 9:08:49 PM UTC-5, dxforth wrote:
> The bigger annoyance is code alignment which some implementations
> put into ," etc instead of handling it separately. ," is a really
> handy function for compiling string constant data; but with
> implementations that variously align, null-terminate and others
> that don't, standardization becomes impossible.

Agree. Caught myself doing that but fixed it:
anew cobble ok
here ," abc" here ," defgh" here ," ij" cr rot tell swap tell tell
abcdefghij ok
--
me

On 2021-09-25 2:51 PM, Paul Rubin wrote:
> Brian Fox <brian.fox@rogers.com> writes:
>> : (S") ( -- c-addr u) R> COUNT 2DUP + ALIGNED >R ;
>
> This is both awesome and terrifying.
>

That made me laugh out loud. :-))
Ya Forth has a few of those.

"Are you nuts? I can't just put things on the hardware stack!"

On 26/09/2021 05:02, S Jack wrote:
> On Friday, September 24, 2021 at 9:08:49 PM UTC-5, dxforth wrote:
>> The bigger annoyance is code alignment which some implementations
>> put into ," etc instead of handling it separately. ," is a really
>> handy function for compiling string constant data; but with
>> implementations that variously align, null-terminate and others
>> that don't, standardization becomes impossible.
>
> Agree. Caught myself doing that but fixed it:
> anew cobble ok
> here ," abc" here ," defgh" here ," ij" cr rot tell swap tell tell
> abcdefghij ok

Unsure what tell does but a test showing the differences might be:

: show ( a n ) 0 ?do count 2dup type + loop drop ;

here ," a" ," bc" ," def" ," ghij" cr 4 show

abcdefghij ok

Trying to find the origin of ," the earliest I've been able to place
it is Laxen/Perry F83; which defined it as:

: ," (S -- )
ASCII " PARSE TUCK 'WORD PLACE 1+ ALLOT ALIGN ;

In L&P 'WORD defaulted to HERE and ALIGN defaulted to NOOP. Given
that definition it's no surprise others copied the alignment.
," was a factor of ." and " and while it could potentially be used
for other things there's no indication L&P ever did.

In his first PC forth, Tom Zimmer copied the L&P definition verbatim
but in F-PC reduced it to:

: ," ( -- )
ASCII " PARSE TUCK HERE PLACE 1+ ALLOT ;

Wil Baden did the same for his 2002 toolkit:

: STRING, ( str len -- )
HERE over 1+ chars ALLOT PLACE ;

: ," [char] " PARSE STRING, ; IMMEDIATE

On 26/09/2021 04:51, Paul Rubin wrote:
> Brian Fox <brian.fox@rogers.com> writes:
>> : (S") ( -- c-addr u) R> COUNT 2DUP + ALIGNED >R ;
>
> This is both awesome and terrifying.
>

Inlining data was a common technique back in the day. This example from
Borland's CP/M Turbo Pascal compiler which outputs 2 bytes representing
the POP IY instruction and automatically skipping over it:

CALL CmpOutCopy
DEFB 2
POP IY
...

On Saturday, September 25, 2021 at 10:36:21 PM UTC-5, dxforth wrote:
> Unsure what tell does but a test showing the differences might be:
>
: TELL COUNT TYPE ;
But your right; my example didn't show anything.
(In habit of seeing the code that doesn't show.)

Here's the Fig definition for compiling a counted string outside a
definition:

: ," ASCII " WORD C@ 1+ ALLOT ; IMMEDIATE

The Fig WORD already moved the counted string to HERE so only needed to
bump count by one and allot. And NO alignment done.

However, a counted string compiled inside a definition is aligned and preceded by a
word that will return to the first cell beyond the string. But the string count is not
altered by the alignment. Alignment bytes are NOT included in the string count.

: S, COUNT TUCK HERE SWAP CMOVE ALLOT ; \ compile counted string content
: FOO "FOO::" ;
: BAR "BAR" ;

HERE FOO S, BAR S,
HERE OVER - TYPE \. FOO::BAR (adjacent text)

Primary words compiling data (or text) outside a definition need not align.
Alignment can be dealt with when needed.

On Saturday, September 25, 2021 at 1:49:22 AM UTC-5, Anton Ertl wrote:
> No. The string is put into the next section, and its address is then
> compiled with LITERAL:

No real magic in sections. The magic is having the string compiled outside the
definition:

HERE ," Hello WORLD " tmp!
: FOO [ tmp@ ] LITERAL COUNT TYPE ;
FOO \. Hello WORLD
--
me

On 27/09/2021 12:31, S Jack wrote:
> On Saturday, September 25, 2021 at 10:36:21 PM UTC-5, dxforth wrote:
>> Unsure what tell does but a test showing the differences might be:
>>
> : TELL COUNT TYPE ;
> But your right; my example didn't show anything.
> (In habit of seeing the code that doesn't show.)
>
> Here's the Fig definition for compiling a counted string outside a
> definition:
>
> : ," ASCII " WORD C@ 1+ ALLOT ; IMMEDIATE
>
> The Fig WORD already moved the counted string to HERE so only needed to
> bump count by one and allot. And NO alignment done.
>
> However, a counted string compiled inside a definition is aligned and preceded by a
> word that will return to the first cell beyond the string. But the string count is not
> altered by the alignment. Alignment bytes are NOT included in the string count.
>
> : S, COUNT TUCK HERE SWAP CMOVE ALLOT ; \ compile counted string content
> : FOO "FOO::" ;
> : BAR "BAR" ;
>
> HERE FOO S, BAR S,
> HERE OVER - TYPE \. FOO::BAR (adjacent text)
>
> Primary words compiling data (or text) outside a definition need not align.
> Alignment can be dealt with when needed.

Unfortunately such things were considered too late - if at all. Whereas most
languages were designed upfront (aka Intelligent Design), Forth seems to have
opted for the Blind Watchmaker route.

On Saturday, September 25, 2021 at 11:52:25 AM UTC-5, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
> >On 24/09/2021 23:43, Brian Fox wrote:
> >> : (S") ( -- c-addr u) R> COUNT 2DUP + ALIGNED >R ;
> ...
> However, this technique incurs a branch misprediction (~20 cycles) on
> return from (S"), so I don't recommend it for native-code systems.
> - anton
> --
Sounds like you're saying:

"any(?) word that modifies its return address will entail a
processor penalty"

Do this include words like LITERAL , as commonly built, that
fetches the compiled value at its return address and then increments its
return address past the compiled value. Or does the modification need
to be greater than some length to be penalized? So jumping around
a single cell is ok but jumping across a string is too much.

Should any return address modification entail a penalty would be an
argument for a third stack, the RACK, for saved data thereby
alleviating return address modifications not having data to branch
around.

If literals are ok and its only a problem with long jumps around strings,
then moving strings out of definitions, such as your use of sections
or by other means, would suffice.
--
me

On 28/09/2021 05:52, S Jack wrote:
> On Saturday, September 25, 2021 at 11:52:25 AM UTC-5, Anton Ertl wrote:
>> dxforth <dxf...@gmail.com> writes:
>> >On 24/09/2021 23:43, Brian Fox wrote:
>> >> : (S") ( -- c-addr u) R> COUNT 2DUP + ALIGNED >R ;
>> ...
>> However, this technique incurs a branch misprediction (~20 cycles) on
>> return from (S"), so I don't recommend it for native-code systems.
>> - anton
>> --
> Sounds like you're saying:
>
> "any(?) word that modifies its return address will entail a
> processor penalty"
>
> Do this include words like LITERAL , as commonly built, that
> fetches the compiled value at its return address and then increments its
> return address past the compiled value. Or does the modification need
> to be greater than some length to be penalized? So jumping around
> a single cell is ok but jumping across a string is too much.
>
> Should any return address modification entail a penalty would be an
> argument for a third stack, the RACK, for saved data thereby
> alleviating return address modifications not having data to branch
> around.
>
> If literals are ok and its only a problem with long jumps around strings,
> then moving strings out of definitions, such as your use of sections
> or by other means, would suffice.

Is it a problem? If inline strings occur infrequently and their
destination is a device, where is the gain? Moving inline strings
to sections is unlikely to have much impact AFAICS. OTOH if one
had sections for other reasons, no harm using it.

S Jack <sdwjack69@gmail.com> writes:
>On Saturday, September 25, 2021 at 11:52:25 AM UTC-5, Anton Ertl wrote:
>> dxforth <dxf...@gmail.com> writes:
>> >On 24/09/2021 23:43, Brian Fox wrote:
>> >> : (S") ( -- c-addr u) R> COUNT 2DUP + ALIGNED >R ;
>> ...
>> However, this technique incurs a branch misprediction (~20 cycles) on
>> return from (S"), so I don't recommend it for native-code systems.
>> - anton
>> --
>Sounds like you're saying:
>
>"any(?) word that modifies its return address will entail a
> processor penalty"

Pretty much, yes.

>Do this include words like LITERAL , as commonly built, that
>fetches the compiled value at its return address and then increments its
>return address past the compiled value.

Yes.

>Or does the modification need
>to be greater than some length to be penalized?

No.

The CPU predicts that the return will return reght behind the call.
If it returns elsewhere, there is a misprediction.

>Should any return address modification entail a penalty would be an
>argument for a third stack, the RACK, for saved data thereby
>alleviating return address modifications not having data to branch
>around.

I don't see how that would help for SLITERAL or LITERAL. Pushing
something on the processor stack in the meantime and popping it is
fine, as long as you return right behind the corresponding call.

- 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 2021: https://euro.theforth.net/2021

On Friday, September 24, 2021 at 6:07:13 AM UTC+2, dxforth wrote:
One thing is for sure: when coded in 4tH is much more concise. I must admit I changed the functionality a bit - this one leaves two transient strings. Obviously, it is a routine to build others with. E.g. one could add a small thingy that concats both strings, types 'em, make them part of a printf() like routine, etc. Same goes for capitalization.

If somebody goes nitpicking - yes, it uses one of 4tH's libs - if you really need the definition of S/HOUR either ask your kindergarten teacher or be just nice. I'll tell you.

include lib/time.4th

create hours
," twelve" ," one" ," two" ," three"
," four" ," five" ," six" ," seven"
," eight" ," nine" ," ten" ," eleven"
does> swap 12 mod th @c count ;

create minutes
," o'clock" ," five after"
," ten after" ," quarter past"
," twenty after" ," twenty-five after"
," half past" ," twenty-five til"
," twenty til" ," quarter til"
," ten til" ," five til"
does> swap th @c count ;

: s>str ( s -- a1 n1 a2 n2 )
150 + s/hour /mod hours 2>r
s/min / 5 / dup minutes rot 2r> rot if 2swap then
;

: smh>str smh>s s>str ; ( s m h -- a1 n1 a2 n2 )

aka smh>str time>str

Hans Bezemer

On Wednesday, September 29, 2021 at 1:55:39 AM UTC+10, the.bee...@gmail.com wrote:
> One thing is for sure: when coded in 4tH is much more concise.

I assume that's due to 4tH hiding the mechanics. AFAICS compiling a string in 4tH
amounts to compiling a reference to it (the string itself goes into a different section) ?

On Tuesday, September 28, 2021 at 6:39:11 AM UTC-5, Anton Ertl wrote:

>The CPU predicts that the return will return reght behind the call.
>If it returns elsewhere, there is a misprediction.

If a value does not entail a penalty, then a headless value could
be used in place of LITERAL (disregarding compliance):

\ XVAL ( x -- XT )
\ Headless value
\ Compile a value holding x and returns the XT of the value.

Also make use of a compiling register:
: %R:
CREATE IMMEDIATE 0 , \ space to hold an XT
DOES> COMPILE, ; \ compile the held XT
%R: %R1
(And IS is modified to accept compiling register as valid target)

HERE ," Hello World!" XVAL is %R1
: foo %R1 COUNT TYPE ;

The string address is compiled in a headless value by XVAL .
The XT of the headless value gets compiled into FOO by means
of the compiling register %R1 .

Not compliant but simple constructs with no impact on FORGET
and MARKER .

The same can be applied to a :NONAME phrase:

:NONAME .... ; is %R1
: FOO ... %R1 ... ; \ effectively a quotation

If want to catch/throw the pesudo-quotation then use combination
:NONAME and XVAL :

:NONAME ... ; XVAL is %R1
: FOO ... %R1 catch ... ;
--
me

On Wednesday, September 29, 2021 at 3:40:01 AM UTC+2, dxforth wrote:
> On Wednesday, September 29, 2021 at 1:55:39 AM UTC+10, the.bee...@gmail.com wrote:
> > One thing is for sure: when coded in 4tH is much more concise.
> I assume that's due to 4tH hiding the mechanics. AFAICS compiling a string in 4tH
> amounts to compiling a reference to it (the string itself goes into a different section) ?
You're completely correct. The reference goes into the Code Segment (R/O), the string itself in the String Segment (R/O). When fetched with @C it returns an address in the Character Segment (R/W) where the temporary string has been copied to.

Another thing is the interpretation semantics of DOES> - but you can do the same thing with gForth too AFAIK. You can port the whole shebang to vanilla Forth using this routine:

[DEFINED] /STRING-SPACE [IF]
( Reserve STRING-SPACE in data-space )
CREATE STRING-SPACE /STRING-SPACE CHARS ALLOT
VARIABLE NEXT-STRING 0 NEXT-STRING !
( " ccc" -- caddr )
: (S,) PARSE
DUP 1+ NEXT-STRING @ + /STRING-SPACE >
ABORT" String space exhausted"
STRING-SPACE NEXT-STRING @ CHARS + >R
DUP 1+ NEXT-STRING +!
R@ PLACE
R> ,
;

: ," [CHAR] " (S,) ; \ 4TH
: ,| [CHAR] | (S,) ; \ 4TH
[ELSE]
..( Warning: ," undefined, needs /STRING-SPACE) CR
[THEN]

Don't forget to define /STRING-SPACE, though.

Hans Bezemer

On Tuesday, September 28, 2021 at 10:11:44 PM UTC-5, S Jack wrote:
> On Tuesday, September 28, 2021 at 6:39:11 AM UTC-5, Anton Ertl wrote:
>
> >The CPU predicts that the return will return reght behind the call.
> >If it returns elsewhere, there is a misprediction.
> If a value does not entail a penalty, then a headless value could
> be used in place of LITERAL (disregarding compliance):

Another way that will work in a Fig Forth is to use PARM to pass
parameters to a definition. PARM makes use of Fig's compiler security
variable CSP which has the data stack location at the beginning of a
colon definition.

\ XVAL ( x -- XT )
\ Headless value
\ Compile x as a headless value, returns XT of the value.
: XVAL ALIGN DOVAL , HERE SWAP , ;

\ PARM ( n -- )
\ Compiling word
\ Compile the nth parameter that was on the data stack
\ at the beginning of a colon definition
\ Note: The n value is normally placed in brackets as it
\ needs to be used at compile time.
: PARM CELLS CSP @ + @ COMPILE, ; IMMEDIATE

HERE ," Hello World!" XVAL
: FOO [ 0 ] PARM COUNT TYPE ;
CR FOO \ Hello World!

HERE ," BOO " XVAL
:NONAME [ 1 ] PARM COUNT TYPE ;
: BAR [ 0 ] PARM ;
CR BAR \ BOO

HERE ," BATS" XVAL
:NONAME [ 1 ] PARM COUNT TYPE ; XVAL
HERE ," &CATS" XVAL
: KOO [ 1 ] PARM CATCH THROW [ 0 ] PARM COUNT TYPE ;
CR KOO \ BATS&CATS
--
me

On 29/09/2021 23:34, Hans Bezemer wrote:
>
> The reference goes into the Code Segment (R/O), the string
> itself in the String Segment (R/O). When fetched with @C it returns an address in the
> Character Segment (R/W) where the temporary string has been copied to.
>
> Another thing is the interpretation semantics of DOES> - but you can do the same thing
> with gForth too AFAIK. You can port the whole shebang to vanilla Forth using this routine:

If the need is occasional, it could be done on the fly:

: ," [char] " parse here over 1+ allot place ;

: $+ ( a -- a' ) count + ; \ traverse
: $, ( a -- a' ) dup , $+ ;
: $,S ( a -- ) begin dup c@ while $, repeat drop ;

here ( a) dup
," Apr" ," Aug" ," Dec" ," Feb"
," Jan" ," Jul" ," Jun" ," Mar"
," May" ," Nov" ," Oct" ," Sep"
0 c,

create StringData $,s \ strings

create MixedData \ strings & integers
4 , $, 8 , $, 12 , $, 2 , $,
1 , $, 7 , $, 6 , $, 3 , $,
5 , $, 11 , $, 10 , $, 9 , $,
drop

On Wednesday, September 29, 2021 at 10:53:59 AM UTC-5, S Jack wrote:
> On Tuesday, September 28, 2021 at 10:11:44 PM UTC-5, S Jack wrote:
> > On Tuesday, September 28, 2021 at 6:39:11 AM UTC-5, Anton Ertl wrote:
The general idea:
create data_space 1000 cells allot
data_space var data_space_ptr
: data_space_here ( -- a ) data_space_ptr @ ;
: data_space_allot ( n -- ) data_space_ptr +! ;
: data_space_align data_space_here aligned data_space_ptr ! ;
: data_space_! ( x -- ) data_space_here ! four data_space_allot ;

: S"
data_space_here
34 word
DUP COUNT data_space_here PLACE C@ 1+ data_space_allot data_space_align
DOVAL data_space_! ( NB 1 )
data_space_here swap data_space_! ( NB 2 , which HERE for xt)
COMPILE, ; IMMEDIATE

: foo S" Hello World! " COUNT TYPE ;
fooHello World!
+echo
Notes:
1. VALUE used in place of LITERAL thus no interruption in
return address flow.
2. My XT was PFA
--
me

On 2021-09-25 19:48, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>> On 24/09/2021 23:43, Brian Fox wrote:
>>> : (S") ( -- c-addr u) R> COUNT 2DUP + ALIGNED >R ;
> ...
>> Even VFX appears to do that.
>
> Yes, surprisingly much return-address manipulation words with native
> code, too. It did not work with gforth-native, because the string
> would land in data space, and the code in code space.
>
> However, this technique incurs a branch misprediction (~20 cycles) on
> return from (S"), so I don't recommend it for native-code systems.

Probably, in native-code systems a native jump over a data block will be
more efficient than return address manipulation.

A native jump can be generated via AHEAD THEN as follows:

: slit, ( c-addr u -- )
>r >r postpone ahead
r> align here r@ allot 0 c, align r@ over >r move
postpone then r> lit, r> lit,
;

: sliteral ( c-addr u -- | c-addr u )
state @ if slit, then
; immediate

Of course, the use of a different section for strings should be even
more efficient, but requires more labor.

Appending the null character at the end makes the Forth string a
null-terminated string at the same time. So when you pass such a string
into external API that requires ASCIIZ, you don't need to make a copy of
this string.

--
Ruvim

On Friday, October 1, 2021 at 12:14:12 AM UTC+2, dxforth wrote:
> On 29/09/2021 23:34, Hans Bezemer wrote:
> >
> > The reference goes into the Code Segment (R/O), the string
> > itself in the String Segment (R/O). When fetched with @C it returns an address in the
> > Character Segment (R/W) where the temporary string has been copied to.
> >
> > Another thing is the interpretation semantics of DOES> - but you can do the same thing
> > with gForth too AFAIK. You can port the whole shebang to vanilla Forth using this routine:
> If the need is occasional, it could be done on the fly:
>
> : ," [char] " parse here over 1+ allot place ;
>
> : $+ ( a -- a' ) count + ; \ traverse
> : $, ( a -- a' ) dup , $+ ;
> : $,S ( a -- ) begin dup c@ while $, repeat drop ;
>
> here ( a) dup
> ," Apr" ," Aug" ," Dec" ," Feb"
> ," Jan" ," Jul" ," Jun" ," Mar"
> ," May" ," Nov" ," Oct" ," Sep"
> 0 c,
>
> create StringData $,s \ strings
>
> create MixedData \ strings & integers
> 4 , $, 8 , $, 12 , $, 2 , $,
> 1 , $, 7 , $, 6 , $, 3 , $,
> 5 , $, 11 , $, 10 , $, 9 , $,
> drop

Very true. We visited that one when I wrote an article on this with Ben Hoyt for FD. The routine I listed was primarily intended for back porting 4tH programs. Sizing the string space isn't that hard, because the 4tH decompile lists exactly how much space the String Segment occupies.

4tH message: No errors at word 695
Object size: 695 words
String size: 1379 chars
Variables : 4 cells
Strings : 4096 chars
Symbols : 52 names
Reliable : Yes

Hans Bezemer

Ruvim <ruvim.pinka@gmail.com> writes:
>A native jump can be generated via AHEAD THEN as follows:
>
> : slit, ( c-addr u -- )
> >r >r postpone ahead
> r> align here r@ allot 0 c, align r@ over >r move
> postpone then r> lit, r> lit,
> ;
>
> : sliteral ( c-addr u -- | c-addr u )
> state @ if slit, then
> ; immediate

Of course, this can be done in a simpler and less broken way by
leaving the STATE-smartness away, e.g.:

: sliteral ( c-addr u -- | c-addr u )
>r >r postpone ahead
r> align here r@ allot 0 c, align r@ over >r move
postpone then r> lit, r> lit,
; immediate

- 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 2021: https://euro.theforth.net/2021