STRING+ and STRING+C 
Author Message
 STRING+ and STRING+C

In OTA there are +STRING and C+STRING , but: a different stack effect
is needed for this functionality.
Namely, the buffer that is written to must not be on the stack top.
I always occasionally had a need for these functionalities,
but only recently I started to pay attention to what namely I need.
Yes, the char/string to be appended must be on top!

What do you think, can/could/should these words go to http://www.*-*-*.com/ ?

CODE STRING+C ( addr len c -- addr len+1 )
        POP ECX
        POP EDI

        MOV BYTE [ECX] [EDI] , BL
        LEA EBX, 1 [ECX]
        PUSH EDI
        exec
c;

\ ( addr1 len1 addr2 len2 -- addr1 len3 )
\ append the text specified by addr2 and len2 to the text of length len2
\ in the buffer at addr1. Return address and length of the resulting text.
\ An ambiguous condition exists if the resulting text is larger
\ than the size of buffer at addr1.
: STRING+ ( bufaddr buftextlen addr len -- bufaddr buftextlen+len )
        2OVER +         ( ba btl a l bta+btl )
        SWAP DUP >R     ( ba btl a bta+btl l ) ( r: l )
        MOVE
        R> +
;

\ ( addr1 len1 c -- addr1 len2 )
\ append c to the text of length len2 in the buffer at addr1.
\ Return address and length of the resulting text.
\ An ambiguous condition exists if the resulting text is larger
\ than the size of buffer at addr1.
: STRING+C ( addr len c -- addr len+1 )
   DUP 2OVER + C! DROP 1+
;



Tue, 05 Apr 2005 03:38:20 GMT  
 STRING+ and STRING+C
Silence is a sign of agreement?

[a claim that the below definitions have *the right* stack effect]

Quote:

> What do you think, can/could/should these words go to http://forth.sf.net ?

[snip]

> \ ( addr1 len1 addr2 len2 -- addr1 len3 )
> \ append the text specified by addr2 and len2 to the text of length len2
> \ in the buffer at addr1. Return address and length of the resulting text.
> \ An ambiguous condition exists if the resulting text is larger
> \ than the size of buffer at addr1.
> : STRING+ ( bufaddr buftextlen addr len -- bufaddr buftextlen+len )
>         2OVER +         ( ba btl a l bta+btl )
>         SWAP DUP >R     ( ba btl a bta+btl l ) ( r: l )
>         MOVE
>         R> +
> ;

> \ ( addr1 len1 c -- addr1 len2 )
> \ append c to the text of length len2 in the buffer at addr1.
> \ Return address and length of the resulting text.
> \ An ambiguous condition exists if the resulting text is larger
> \ than the size of buffer at addr1.
> : STRING+C ( addr len c -- addr len+1 )
>    DUP 2OVER + C! DROP 1+
> ;



Thu, 07 Apr 2005 15:44:06 GMT  
 STRING+ and STRING+C
not necessarily - it could also mean ignorance.
In this case to mean that no one will implement it
and the word will be nothing else than "reserved".
Quote:

> Silence is a sign of agreement?


> [a claim that the below definitions have *the right* stack effect]

>>What do you think, can/could/should these words go to http://forth.sf.net ?

> [snip]

>>\ ( addr1 len1 addr2 len2 -- addr1 len3 )
>>\ append the text specified by addr2 and len2 to the text of length len2
>>\ in the buffer at addr1. Return address and length of the resulting text.
>>\ An ambiguous condition exists if the resulting text is larger
>>\ than the size of buffer at addr1.
>>: STRING+ ( bufaddr buftextlen addr len -- bufaddr buftextlen+len )
>>        2OVER +         ( ba btl a l bta+btl )
>>        SWAP DUP >R     ( ba btl a bta+btl l ) ( r: l )
>>        MOVE
>>        R> +
>>;

>>\ ( addr1 len1 c -- addr1 len2 )
>>\ append c to the text of length len2 in the buffer at addr1.
>>\ Return address and length of the resulting text.
>>\ An ambiguous condition exists if the resulting text is larger
>>\ than the size of buffer at addr1.
>>: STRING+C ( addr len c -- addr len+1 )
>>   DUP 2OVER + C! DROP 1+
>>;



Thu, 07 Apr 2005 17:57:45 GMT  
 STRING+ and STRING+C

Quote:

> not necessarily - it could also mean ignorance.
> In this case to mean that no one will implement it
> and the word will be nothing else than "reserved".


>> Silence is a sign of agreement?

In my case it's more that I'm really uncertain about what to
say, rather than a matter of ignorance.

I think the words could be useful.  The names I guess satisfy a
sufficient ugliness principle (no offense intended).  I would
probably use something like S+ and C+ as synonyms in my
applications, never mind the possibility of confusion
(especially for C+), so I'm not really worried about losing the
names.

<digression>
But we all recognize the issue that today's name choices get
visited onto posterity.

I sometimes wonder about a principle of *maximum*
ugliness--giving candidates for common use names like "N1000",
"N1001", etc., supplied by an ugly names keeper, with the
understanding that users will freely replace them by local
synonyms for their applications. :-)
</digression>

-- David



Thu, 07 Apr 2005 23:50:24 GMT  
 STRING+ and STRING+C

Quote:


>> not necessarily - it could also mean ignorance.
>> In this case to mean that no one will implement it
>> and the word will be nothing else than "reserved".


>>> Silence is a sign of agreement?

> In my case it's more that I'm really uncertain about what to say, rather
> than a matter of ignorance.

> I think the words could be useful.  The names I guess satisfy a
> sufficient ugliness principle (no offense intended).

Well, I did not want it to sound too negative, the
ignorance is more to the case of actual use case
of these words. I didn't need anything similar so
far, storing words had been always special to the
string representation in the target buffer (how
to determine the (new) length there?), so that
I can not see so far a need to implement it, ye
know.

As for the naming - the only word with a STRING
prefix is called "string," in my system, I just
need to wonder what the other words are that
mlg thinks of that could be in this prefix group.
(well, I like groupnames, there are too many
words to remember even now...)



Fri, 08 Apr 2005 00:30:00 GMT  
 STRING+ and STRING+C

Quote:



> >> not necessarily - it could also mean ignorance.
> >> In this case to mean that no one will implement it
> >> and the word will be nothing else than "reserved".


> >>> Silence is a sign of agreement?

> > In my case it's more that I'm really uncertain about what to say, rather
> > than a matter of ignorance.

> > I think the words could be useful.  The names I guess satisfy a
> > sufficient ugliness principle (no offense intended).

> Well, I did not want it to sound too negative, the
> ignorance is more to the case of actual use case
> of these words. I didn't need anything similar so
> far, storing words had been always special to the
> string representation in the target buffer (how
> to determine the (new) length there?), so that
> I can not see so far a need to implement it, ye
> know.

The string representation in the target buffer is
the text and (addr,len).

The last two cases where I needed STRING+ were:
1) paths for include
2) conversion of source into label names for generated test programs
(to show comments, I reused the disassembler's ability to show names).

STRIING+C was needed in communication routines like ACCEPT
(but the difference is that speed was important there,
since this was on a board communicating via RS-232 on
a high speed.)

And yes, I needed '/' STRING+C for include paths.

Quote:

> As for the naming - the only word with a STRING
> prefix is called "string," in my system, I just
> need to wonder what the other words are that
> mlg thinks of that could be in this prefix group.

/STRING , of course!

(Indeed, what we have for strings is addition and division.)

- Show quoted text -

Quote:
> (well, I like groupnames, there are too many
> words to remember even now...)



Fri, 08 Apr 2005 01:16:19 GMT  
 STRING+ and STRING+C

Quote:




>>>>not necessarily - it could also mean ignorance.
>>>>In this case to mean that no one will implement it
>>>>and the word will be nothing else than "reserved".


>>>>>Silence is a sign of agreement?

>>>In my case it's more that I'm really uncertain about what to say, rather
>>>than a matter of ignorance.

>>>I think the words could be useful.  The names I guess satisfy a
>>>sufficient ugliness principle (no offense intended).

>>Well, I did not want it to sound too negative, the
>>ignorance is more to the case of actual use case
>>of these words. I didn't need anything similar so
>>far, storing words had been always special to the
>>string representation in the target buffer (how
>>to determine the (new) length there?), so that
>>I can not see so far a need to implement it, ye
>>know.

> The string representation in the target buffer is
> the text and (addr,len).

> The last two cases where I needed STRING+ were:
> 1) paths for include
> 2) conversion of source into label names for generated test programs
> (to show comments, I reused the disassembler's ability to show names).

+PLACE

- Show quoted text -

Quote:

> STRIING+C was needed in communication routines like ACCEPT
> (but the difference is that speed was important there,
> since this was on a board communicating via RS-232 on
> a high speed.)

> And yes, I needed '/' STRING+C for include paths.

>>As for the naming - the only word with a STRING
>>prefix is called "string," in my system, I just
>>need to wonder what the other words are that
>>mlg thinks of that could be in this prefix group.

> /STRING , of course!

aaah, right, 'forgot that one...

Quote:

> (Indeed, what we have for strings is addition and division.)

may be we have to build a list of words and which of
those maps to those in C's string.h list of string functions.


Fri, 08 Apr 2005 02:35:15 GMT  
 STRING+ and STRING+C



Quote:

> <digression>
> But we all recognize the issue that today's name choices get
> visited onto posterity.

> I sometimes wonder about a principle of *maximum*
> ugliness--giving candidates for common use names like "N1000",
> "N1001", etc., supplied by an ugly names keeper, with the
> understanding that users will freely replace them by local
> synonyms for their applications. :-)
> </digression>

    In a sense, I agree.  I think the reserved words should use "ugly" names
(not quite as ugly as your examples!) and leave the "pretty" names for
application usage.

--

-Gary Chanson (MVP for Windows SDK)
-Software Consultant (Embedded systems and Real Time Controls)

-War is the last resort of the incompetent.



Fri, 08 Apr 2005 02:14:31 GMT  
 STRING+ and STRING+C

Quote:



>><digression>
>>But we all recognize the issue that today's name choices get
>>visited onto posterity.

>>I sometimes wonder about a principle of *maximum*
>>ugliness--giving candidates for common use names like "N1000",
>>"N1001", etc., supplied by an ugly names keeper, with the
>>understanding that users will freely replace them by local
>>synonyms for their applications. :-)
>></digression>

>     In a sense, I agree.  I think the reserved words should use "ugly" names
> (not quite as ugly as your examples!) and leave the "pretty" names for
> application usage.

What about starting a list of "pretty words" that *should* be
left to application usage? Or atleast specified that these
*must* be wrapped in a wordset to get at them conditionally
if there are a number of flavours around - the forth base
system does not deal with a wordset or other module system...


Fri, 08 Apr 2005 04:39:21 GMT  
 STRING+ and STRING+C

Quote:





[..]
> >>[...] actual use case
> >>of these words. I didn't need anything similar so
> >>far, storing words had been always special to the
> >>string representation in the target buffer (how
> >>to determine the (new) length there?), so that
> >>I can not see so far a need to implement it, ye
> >>know.

> > The string representation in the target buffer is
> > the text and (addr,len).

> > The last two cases where I needed STRING+ were:
> > 1) paths for include
[..]

> +PLACE

len>255


Fri, 08 Apr 2005 05:38:06 GMT  
 STRING+ and STRING+C

Quote:






> [..]

>>>>[...] actual use case
>>>>of these words. I didn't need anything similar so
>>>>far, storing words had been always special to the
>>>>string representation in the target buffer (how
>>>>to determine the (new) length there?), so that
>>>>I can not see so far a need to implement it, ye
>>>>know.

>>>The string representation in the target buffer is
>>>the text and (addr,len).

>>>The last two cases where I needed STRING+ were:
>>>1) paths for include

> [..]

>>+PLACE

> len>255

other string buffer type, e.g. packed strings,
with a method +$PLACE, or z-strings, with +ZPLACE


Fri, 08 Apr 2005 06:08:21 GMT  
 STRING+ and STRING+C

Quote:



....

> >>>>[...] actual use case
> >>>>of these words. I didn't need anything similar so
> >>>>far,

> >>>The string representation in the target buffer is
> >>>the text and (addr,len).

> >>>The last two cases where I needed STRING+ were:
> >>>1) paths for include

> > [..]

> >>+PLACE

> > len>255

> other string buffer type, e.g. packed strings,
> with a method +$PLACE, or z-strings, with +ZPLACE

That would need a library. Maybe, a memory allocation scheme.
I want to use just (addr,len).

IOW, I do need additional string operations, but I do not need
a string data type. [ (addr,len) is enough.]



Fri, 08 Apr 2005 07:02:45 GMT  
 STRING+ and STRING+C

Quote:




> ....


>>>>>>[...] actual use case
>>>>>>of these words. I didn't need anything similar so
>>>>>>far,

>>>>>The string representation in the target buffer is
>>>>>the text and (addr,len).

>>>>>The last two cases where I needed STRING+ were:
>>>>>1) paths for include

>>>[..]

>>>>+PLACE

>>>len>255

>>other string buffer type, e.g. packed strings,
>>with a method +$PLACE, or z-strings, with +ZPLACE

> That would need a library. Maybe, a memory allocation scheme.
> I want to use just (addr,len).

> IOW, I do need additional string operations, but I do not need
> a string data type. [ (addr,len) is enough.]

which let's us come back to the original point in the discussion
since you seem to have a use case where you can disregard the
memory representation and keep the length on stack for immediate
usage with a string-span function... and I said that's a rare
occasion for me. In fact, even paths can be limited to 255 chars
and where that is not quite possible they are z-strings anyway.


Fri, 08 Apr 2005 07:37:09 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Ada String Issue: String within Strings

2. string = string(i:j) // string(k:n)

3. BUG: Scientific Number to String/String to Number

4. Picture to String/String to Picture

5. string variable and string field

6. How to convert binary string to char string ?

7. CW strings (was CW1501 strings)

8. Array to String and String to Array

9. Proposal v2 /was: Standardising string primitives (was: Re: String)

10. Standardising string primitives (was: Re: String)

11. OT QuotingRe: Standardising string primitives (was: Re: String)

 

 
Powered by phpBB® Forum Software