From Newsgroup: comp.lang.forth

I recall the definition of coroutine call:

CO :
Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed

HEX: " temparily switch to HEX for the duration of the current
definition."

A typical use of HEX: is as follows

( print BYTE in hex )
: B. HEX: S>D <# # # #> TYPE ;
( print SINGLE in hex )
: 4? 1+ 4 MOD 0= IF &, HOLD THEN ; \ print &, at regular intervals.
: H. HEX: S>D <# 2 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;
( print DOUBLE in hex )
: DH. HEX: <# 4 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;

HEX: is an example use of the use of CO (coroutine).
VARIABLE BASE-TEMP
: HEX:
BASE @ BASE-TEMP !
HEX CO
BASE-TEMP @ BASE !
;
This is ugly so you are tempted to do

: HEX:
BASE @ >R
HEX CO
R> BASE !
;
This doesn't work. The return address is in the way,
assuming there is a return address on the stack.
This also makes the code implementation dependant.
(Marcel Hendrix's >S and S> however would work.)

: HEX:
R> BASE @ >R >R
HEX CO
R> BASE !
;

I hate TUCK ( a b -- b a b )
but I like RTUCK
"save the top of the stack under the return address of a high
level word."

: HEX:
BASE @ RTUCK
HEX CO
R> BASE !
;

Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 17-03-2026 15:31, albert@spenarnc.xs4all.nl wrote:

I recall the definition of coroutine call:

CO :
Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed

HEX: " temparily switch to HEX for the duration of the current
definition."

A typical use of HEX: is as follows

( print BYTE in hex )
: B. HEX: S>D <# # # #> TYPE ;
( print SINGLE in hex )
: 4? 1+ 4 MOD 0= IF &, HOLD THEN ; \ print &, at regular intervals.
: H. HEX: S>D <# 2 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;
( print DOUBLE in hex )
: DH. HEX: <# 4 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;

HEX: is an example use of the use of CO (coroutine).
VARIABLE BASE-TEMP
: HEX:
BASE @ BASE-TEMP !
HEX CO
BASE-TEMP @ BASE !
;
This is ugly so you are tempted to do

: HEX:
BASE @ >R
HEX CO
R> BASE !
;
This doesn't work. The return address is in the way,
assuming there is a return address on the stack.
This also makes the code implementation dependant.
(Marcel Hendrix's >S and S> however would work.)

: HEX:
R> BASE @ >R >R
HEX CO
R> BASE !
;

I hate TUCK ( a b -- b a b )
but I like RTUCK
"save the top of the stack under the return address of a high
level word."

: HEX:
BASE @ RTUCK
HEX CO
R> BASE !
;

Groetjes Albert

"This is ugly". Yeah. Create a new stack, dump it there. :-)

Hans Bezemer

: stack dup ! ; ( stack --)
: a@ @ @ ; ( stack -- n)
: >a 1 cells over +! @ ! ; ( n stack --)
: a> dup a@ -1 cells rot +! ; ( stack -- n)
: adepth dup @ swap - ; ( stack -- n)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 18/03/2026 1:31 am, albert@spenarnc.xs4all.nl wrote:

I recall the definition of coroutine call:

CO :
Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed

HEX: " temparily switch to HEX for the duration of the current
definition."

A typical use of HEX: is as follows

( print BYTE in hex )
: B. HEX: S>D <# # # #> TYPE ;
( print SINGLE in hex )
: 4? 1+ 4 MOD 0= IF &, HOLD THEN ; \ print &, at regular intervals.
: H. HEX: S>D <# 2 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;
( print DOUBLE in hex )
: DH. HEX: <# 4 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;

HEX: is an example use of the use of CO (coroutine).
VARIABLE BASE-TEMP
: HEX:
BASE @ BASE-TEMP !
HEX CO
BASE-TEMP @ BASE !
;
This is ugly so you are tempted to do

go back to regular methods?

: (H.N) ( u +n -- a2 u2 )
base @ >r hex <# 0 tuck ?do #
i 1+ 4 mod 0= if [char] , hold then loop #>
over c@ [char] , = 1 and /string r> base ! ;

: (H.) ( u -- adr len ) [ 2 cells ] literal (h.n) ;
: (HW.) ( u -- adr len ) 4 (h.n) ;
: (HB.) ( u -- adr len ) 2 (h.n) ;
: (HD.) ( ud -- adr len ) (h.) dup >r holds (h.) r> 1+ negate /string ;

-1 (h.) type FFFF,FFFF,FFFF,FFFF ok
-1 (hw.) type FFFF ok
-1 (hb.) type FF ok
-1 -1 (hd.) type FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF ok

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <69b99106$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:

On 18/03/2026 1:31 am, albert@spenarnc.xs4all.nl wrote:

I recall the definition of coroutine call:

CO :
Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed

HEX: " temparily switch to HEX for the duration of the current
definition."

A typical use of HEX: is as follows

( print BYTE in hex )
: B. HEX: S>D <# # # #> TYPE ;
( print SINGLE in hex )
: 4? 1+ 4 MOD 0= IF &, HOLD THEN ; \ print &, at regular intervals.
: H. HEX: S>D <# 2 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;
( print DOUBLE in hex )
: DH. HEX: <# 4 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;

HEX: is an example use of the use of CO (coroutine).
VARIABLE BASE-TEMP
: HEX:
BASE @ BASE-TEMP !
HEX CO
BASE-TEMP @ BASE !
;
This is ugly so you are tempted to do

go back to regular methods?

: (H.N) ( u +n -- a2 u2 )
base @ >r hex <# 0 tuck ?do #
i 1+ 4 mod 0= if [char] , hold then loop #>
over c@ [char] , = 1 and /string r> base ! ;

: (H.) ( u -- adr len ) [ 2 cells ] literal (h.n) ;
: (HW.) ( u -- adr len ) 4 (h.n) ;
: (HB.) ( u -- adr len ) 2 (h.n) ;
: (HD.) ( ud -- adr len ) (h.) dup >r holds (h.) r> 1+ negate /string ;

-1 (h.) type FFFF,FFFF,FFFF,FFFF ok
-1 (hw.) type FFFF ok
-1 (hb.) type FF ok
-1 -1 (hd.) type FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF ok

HEX: was the proposal. The other words are illustration.
Exercise for the reader:
give an example where HEX: would be useful for number
input.

A free stack >S S> (mhx) or an extra stack defined for this
purpose (Bezemer) helps to define HEX: without RTUCK.

The ugly solution (using BASE-TEMP) could be adequate.
Re-entrancy is overrated anyway.

Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 18/03/2026 10:47 pm, albert@spenarnc.xs4all.nl wrote:

In article <69b99106$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:

On 18/03/2026 1:31 am, albert@spenarnc.xs4all.nl wrote:

I recall the definition of coroutine call:

CO :
Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed

HEX: " temparily switch to HEX for the duration of the current
definition."

A typical use of HEX: is as follows

( print BYTE in hex )
: B. HEX: S>D <# # # #> TYPE ;
( print SINGLE in hex )
: 4? 1+ 4 MOD 0= IF &, HOLD THEN ; \ print &, at regular intervals. >>> : H. HEX: S>D <# 2 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;
( print DOUBLE in hex )
: DH. HEX: <# 4 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;

HEX: is an example use of the use of CO (coroutine).
VARIABLE BASE-TEMP
: HEX:
BASE @ BASE-TEMP !
HEX CO
BASE-TEMP @ BASE !
;
This is ugly so you are tempted to do

go back to regular methods?

: (H.N) ( u +n -- a2 u2 )
base @ >r hex <# 0 tuck ?do #
i 1+ 4 mod 0= if [char] , hold then loop #>
over c@ [char] , = 1 and /string r> base ! ;

: (H.) ( u -- adr len ) [ 2 cells ] literal (h.n) ;
: (HW.) ( u -- adr len ) 4 (h.n) ;
: (HB.) ( u -- adr len ) 2 (h.n) ;
: (HD.) ( ud -- adr len ) (h.) dup >r holds (h.) r> 1+ negate /string ;

-1 (h.) type FFFF,FFFF,FFFF,FFFF ok
-1 (hw.) type FFFF ok
-1 (hb.) type FF ok
-1 -1 (hd.) type FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF ok

HEX: was the proposal. The other words are illustration.

As a proposal what does HEX: fix? The words you use to illustrate
don't appear to offer advantage. Poorly factored hex output words
are not a good use case for HEX: . Do you have any other examples?

Exercise for the reader:
give an example where HEX: would be useful for number
input.

A free stack >S S> (mhx) or an extra stack defined for this
purpose (Bezemer) helps to define HEX: without RTUCK.

The ugly solution (using BASE-TEMP) could be adequate.
Re-entrancy is overrated anyway.

Groetjes Albert

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 19/03/2026 11:51 am, dxf wrote:

On 18/03/2026 10:47 pm, albert@spenarnc.xs4all.nl wrote:

In article <69b99106$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:

On 18/03/2026 1:31 am, albert@spenarnc.xs4all.nl wrote:

I recall the definition of coroutine call:

CO :
Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed

HEX: " temparily switch to HEX for the duration of the current
definition."

A typical use of HEX: is as follows

( print BYTE in hex )
: B. HEX: S>D <# # # #> TYPE ;
( print SINGLE in hex )
: 4? 1+ 4 MOD 0= IF &, HOLD THEN ; \ print &, at regular intervals. >>>> : H. HEX: S>D <# 2 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;
( print DOUBLE in hex )
: DH. HEX: <# 4 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;

HEX: is an example use of the use of CO (coroutine).
VARIABLE BASE-TEMP
: HEX:
BASE @ BASE-TEMP !
HEX CO
BASE-TEMP @ BASE !
;
This is ugly so you are tempted to do

go back to regular methods?

: (H.N) ( u +n -- a2 u2 )
base @ >r hex <# 0 tuck ?do #
i 1+ 4 mod 0= if [char] , hold then loop #>
over c@ [char] , = 1 and /string r> base ! ;

: (H.) ( u -- adr len ) [ 2 cells ] literal (h.n) ;
: (HW.) ( u -- adr len ) 4 (h.n) ;
: (HB.) ( u -- adr len ) 2 (h.n) ;
: (HD.) ( ud -- adr len ) (h.) dup >r holds (h.) r> 1+ negate /string ; >>>
-1 (h.) type FFFF,FFFF,FFFF,FFFF ok
-1 (hw.) type FFFF ok
-1 (hb.) type FF ok
-1 -1 (hd.) type FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF ok

HEX: was the proposal. The other words are illustration.

As a proposal what does HEX: fix? The words you use to illustrate
don't appear to offer advantage. Poorly factored hex output words
are not a good use case for HEX: . Do you have any other examples?

p.s. Your examples did illustrate the utility of separators in hex output
so thanks for that.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <69bb7284$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:

On 19/03/2026 11:51 am, dxf wrote:

On 18/03/2026 10:47 pm, albert@spenarnc.xs4all.nl wrote:

In article <69b99106$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote: >>>> On 18/03/2026 1:31 am, albert@spenarnc.xs4all.nl wrote:

I recall the definition of coroutine call:

CO :
Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed

HEX: " temparily switch to HEX for the duration of the current
definition."

<SNIP>

A typical use of HEX: is as follows

( print BYTE in hex )
: B. HEX: S>D <# # # #> TYPE ;

HEX: was the proposal. The other words are illustration.

As a proposal what does HEX: fix? The words you use to illustrate
don't appear to offer advantage. Poorly factored hex output words
are not a good use case for HEX: . Do you have any other examples?

HEX: " temporarily switch to HEX for the duration of the current
definition."

It is an advantage that you do not need to separate saving and restoring.
If that doesn't appeal to you, so be it.

Groetjes Albert


--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 18-03-2026 12:47, albert@spenarnc.xs4all.nl wrote:

In article <69b99106$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:

On 18/03/2026 1:31 am, albert@spenarnc.xs4all.nl wrote:

I recall the definition of coroutine call:

CO :
Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed

HEX: " temparily switch to HEX for the duration of the current
definition."

A typical use of HEX: is as follows

( print BYTE in hex )
: B. HEX: S>D <# # # #> TYPE ;
( print SINGLE in hex )
: 4? 1+ 4 MOD 0= IF &, HOLD THEN ; \ print &, at regular intervals. >>> : H. HEX: S>D <# 2 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;
( print DOUBLE in hex )
: DH. HEX: <# 4 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;

HEX: is an example use of the use of CO (coroutine).
VARIABLE BASE-TEMP
: HEX:
BASE @ BASE-TEMP !
HEX CO
BASE-TEMP @ BASE !
;
This is ugly so you are tempted to do

go back to regular methods?

: (H.N) ( u +n -- a2 u2 )
base @ >r hex <# 0 tuck ?do #
i 1+ 4 mod 0= if [char] , hold then loop #>
over c@ [char] , = 1 and /string r> base ! ;

: (H.) ( u -- adr len ) [ 2 cells ] literal (h.n) ;
: (HW.) ( u -- adr len ) 4 (h.n) ;
: (HB.) ( u -- adr len ) 2 (h.n) ;
: (HD.) ( ud -- adr len ) (h.) dup >r holds (h.) r> 1+ negate /string ;

-1 (h.) type FFFF,FFFF,FFFF,FFFF ok
-1 (hw.) type FFFF ok
-1 (hb.) type FF ok
-1 -1 (hd.) type FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF ok

HEX: was the proposal. The other words are illustration.
Exercise for the reader:
give an example where HEX: would be useful for number
input.

A free stack >S S> (mhx) or an extra stack defined for this
purpose (Bezemer) helps to define HEX: without RTUCK.

The ugly solution (using BASE-TEMP) could be adequate.
Re-entrancy is overrated anyway.

Groetjes Albert

[UNDEFINED] base&exec [IF] ( xt n -- )
: base&exec base @ >r base ! execute r> base ! ;
[THEN]

Does the same thing:

: B. [: S>D <# # # #> TYPE ;] 16 base&exec ;

BTW - alternative solution. I don't claim it's fundamentally better.

Hans Bezemer



--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

albert@spenarnc.xs4all.nl wrote:

: HEX:
BASE @ RTUCK
HEX CO
R> BASE !
;

RTUCK is interesting because it names a pattern that most Forth
programmers do manually with R> ... >R shuffling. The fact that
you need it at all is telling -- the return stack is doing double
duty as both control flow and temporary storage, and those two
uses fight each other whenever you try to combine them.

CO makes it worse because it manipulates the return address as
data. So you've got three things on the return stack: addresses
that are control flow, values you're temporarily storing, and
the address that CO needs to swap. RTUCK at least makes the
intent clear -- "I know there's a return address on top and I
want to get under it."

Marcel's >S / S> (separate scratch stack) would solve this
more cleanly but at the cost of another stack. The Forth
minimalist in me respects RTUCK as the cheaper fix. Though
it does assume a specific return stack layout, which is the
thing you were trying to avoid.

The deeper question: is CO worth the return stack gymnastics?
The alternative -- a VARIABLE like BASE-TEMP -- is ugly but
at least it doesn't care what's on R.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

thresh3@fastmail.com (Lev) writes:

The deeper question: is CO worth the return stack gymnastics?
The alternative -- a VARIABLE like BASE-TEMP -- is ugly but
at least it doesn't care what's on R.

It has to be on a stack so you can nest such words. The RTUCK / CO
trick there was very clever!

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

Paul Rubin <no.email@nospam.invalid> wrote:

It has to be on a stack so you can nest such words. The RTUCK / CO
trick there was very clever!

You're right -- I missed the nesting case. If you had
HEX: inside DEC: (or whatever), a VARIABLE gets clobbered.
The return stack handles nesting naturally because each
CO activation gets its own frame.

So the question isn't "variable vs return stack" but
"return stack vs a separate user stack." Marcel's >S / S>
would work and nest correctly without the RTUCK gymnastics,
but adds a third stack to manage. RTUCK is the minimum-cost
solution that handles nesting correctly on the existing
hardware.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

Paul Rubin <no.email@nospam.invalid> wrote:

It has to be on a stack so you can nest such words. The RTUCK / CO
trick there was very clever!

You're right, nesting kills the variable approach. I wasn't thinking
about recursive or mutually-calling words that both need their own
saved state. A variable gives you one slot; the return stack gives
you as many as the call depth.

The cleverness of CO is how it avoids the usual Forth pattern of
"I need temporary storage, let me abuse the return stack and hope
nothing else touches it." CO makes the return stack usage structured
-- you put something there and get it back in a predictable way,
rather than bare >R / R> with fingers crossed.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <nnd$21de7487$4745b8b3@6099a36497d3ef38>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 18/03/2026 1:31 am, albert@spenarnc.xs4all.nl wrote:

VARIABLE BASE-TEMP
: HEX:
BASE @ BASE-TEMP !
HEX CO
BASE-TEMP @ BASE !
;

Groetjes Albert

[UNDEFINED] base&exec [IF] ( xt n -- )
: base&exec base @ >r base ! execute r> base ! ;
[THEN]

Does the same thing:

: B. [: S>D <# # # #> TYPE ;] 16 base&exec ;

BTW - alternative solution. I don't claim it's fundamentally better.

If you have lambda's this is certainly a reasonable alternative.

Hans Bezemer

--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <20260319183826.lev.rtuck@thresh3>,
Lev <thresh3@fastmail.com> wrote:

albert@spenarnc.xs4all.nl wrote:

: HEX:
BASE @ RTUCK
HEX CO
R> BASE !
;

RTUCK is interesting because it names a pattern that most Forth
programmers do manually with R> ... >R shuffling. The fact that
you need it at all is telling -- the return stack is doing double
duty as both control flow and temporary storage, and those two
uses fight each other whenever you try to combine them.

You overlook an advantage that I have not stressed (but this
makes the name dubious). It makes it more abstract.
In this situation you could use RTUCK, irrespective of whether
the return stack is actually used for control.
It could also work in a
(non standard) Forth that use two items on the stack to
denote (segment, local address).
So given it a name and specifying it, addresses the problems
that you need more carnal knowledge to used it.

Suppose you have defined a free R-stack. You can do that, nobody
forces you to use it for nesting.
Then you can define RTUCK as >R and everything is fine.
Note that there is nothing in CO that refers to the return stack.

CO makes it worse because it manipulates the return address as
data. So you've got three things on the return stack: addresses
that are control flow, values you're temporarily storing, and
the address that CO needs to swap. RTUCK at least makes the
intent clear -- "I know there's a return address on top and I
want to get under it."

Definition of CO:
Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed.

Where is the return stack mentioned? Not in the specification.
This is common among Forthers, only think in implementations.

Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

albert@spenarnc.xs4all.nl writes:

but I like RTUCK
"save the top of the stack under the return address of a high
level word."

Does this work?

: rtuck ( a r:x -- r:a r:x ) r> r> rot >r >r >r ;
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

Am 21.03.2026 um 10:31 schrieb Paul Rubin:

albert@spenarnc.xs4all.nl writes:

but I like RTUCK
"save the top of the stack under the return address of a high
level word."

Does this work?

: rtuck ( a r:x -- r:a r:x ) r> r> rot >r >r >r ;

If someone is tinkering with their own system, RTUCK might well be quite useful. But its portability is pretty much non-existent, because there’s
no guarantee how many cells a return address of a word uses, or whether
a word might be altered by compiler optimisations.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <87341tcyvz.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:

albert@spenarnc.xs4all.nl writes:

but I like RTUCK
"save the top of the stack under the return address of a high
level word."

Does this work?

: rtuck ( a r:x -- r:a r:x ) r> r> rot >r >r >r ;

In most implementations, probably yes. Certainly in ciforth.

RTUCK was not totally serious.

It is most useful in combination with CO.
Then it can be made abstract.

CO:
Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed. This use can be nested.

( x -- )

CO : Save temporily such that it can be recovered by CO>

after an optional coroutine call. Can be nested.
See also CO.

( -- x)

: Recover what has been temporarily saved with >CO

With this wordset:
The return stack must not be engaged, as with >R and R> , or DO and LOOP .

CO is a single instruction low level word in i86.

CO and CO> are short slightly larger than >R R>.

Note that you can use >CO / CO> instead of >R / R> , the coroutine call
is not essential.

This ciforth code should be readable given i86, and
HIP (high level interpreter pointer)
RPO (Return stack pointer)
POP / PUSH (implies data stack)
_C{ } comment
CODE_HEADER(name towards Forth, name in assembler source)
BX is BX, EBX OR RBX depending on cell width.

CODE_HEADER({CO},{CO})
XCHG HIP,[RPO]
_NEXT

Compare >CO with >R
CODE_HEADER({>R},{TOR}) _C{ (R1) <- (S1)}
POP BX _C{GET STACK PARAMETER}
LEA RPO,[RPO - _CELLS(1)] _C{MOVE RETURN STACK DOWN}
MOV [RPO],BX _C{ADD TO RETURN STACK}
_NEXT

CODE_HEADER({>CO},{TOCO})
MOV AX, [RPO]
LEA RPO,[RPO - _CELLS(1)] _C{HOLE IN RETURN STACK }
MOV [RPO], AX

POP BX _C{GET STACK PARAMETER}
MOV [RPO + _CELLS(1)],BX _C{FILL HOLE}
_NEXT

This hardly make sense to code this in high level "portable"
because high level makes it harder, and slower.

: HEX:
BASE @ >CO
HEX CO
CO> BASE !
;

An application in combination with decoration:
CSD gives an exception if the word decorated change stack depth:
(DSP@ gives the data stack pointer, probably in a register. )

: CSD DSP@ >CO CO DSP@ CO> <> 1001 AND THROW ;

' CSD ' my-word decorated

(or use DEPTH instead of DSP@ )

Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <nnd$06efed74$3ea7e983@cc9294320063f6e2>,
<albert@spenarnc.xs4all.nl> wrote:
<SNIP>

This ciforth code should be readable given i86, and
HIP (high level interpreter pointer)
RPO (Return stack pointer)
POP / PUSH (implies data stack)
_C{ } comment
CODE_HEADER(name towards Forth, name in assembler source)
BX is BX, EBX OR RBX depending on cell width.

CODE_HEADER({CO},{CO})
XCHG HIP,[RPO]
_NEXT

Compare >CO with >R
CODE_HEADER({>R},{TOR}) _C{ (R1) <- (S1)}
POP BX _C{GET STACK PARAMETER}
LEA RPO,[RPO - _CELLS(1)] _C{MOVE RETURN STACK DOWN}
MOV [RPO],BX _C{ADD TO RETURN STACK}
_NEXT

CODE_HEADER({>CO},{TOCO})
MOV AX, [RPO]
LEA RPO,[RPO - _CELLS(1)] _C{HOLE IN RETURN STACK }
MOV [RPO], AX

POP BX _C{GET STACK PARAMETER}
MOV [RPO + _CELLS(1)],BX _C{FILL HOLE}
_NEXT

This hardly make sense to code this in high level "portable"
because high level makes it harder, and slower.

Surprise, surprise.
Replacing >R by >CO and R> by CO>
all code using R> and >R keeps working!
This includes the return stack manipulation in CATCH and THROW.
Only ;CODE needs a rework. (Who uses that?)
Push a don't care then drops it.

_ R> DROP

Groetjes Albert

--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21d-Linux NewsLink 1.2