6 Glossary

6.1.1240 DO CORE

Interpretation:

Interpretation semantics for this word are undefined.

Compilation:

( C: -- do-sys )

Place do-sys onto the control-flow stack. Append the run-time semantics given below to the current definition. The semantics are incomplete until resolved by a consumer of do-sys such as LOOP.

Run-time:

( n₁ | u₁ n₂ | u₂ -- ) ( R: -- loop-sys )

Set up loop control parameters with index n₂ | u₂ and limit n₁ | u₁. An ambiguous condition exists if n₁ | u₁ and n₂ | u₂ are not both the same type. Anything already on the return stack becomes unavailable until the loop-control parameters are discarded.

See:

3.2.3.2 Control-flow stack, 6.1.0140 +LOOP, 6.1.1800 LOOP, A.6.1.1240 DO.

Rationale:

Typical use:

: X ... limit first DO ... LOOP ;

: X ... limit first DO ... step +LOOP ;

Testing:

See F.6.1.1800 LOOP, F.6.1.0140 +LOOP, F.6.1.1730 J, F.6.1.1760 LEAVE, F.6.1.2380 UNLOOP.

ContributeContributions

lmr [331] loopsys in data?Request for clarification2024-01-08 06:17:40

Would it be conforming for an implementation to generate a new loopsys in data space for every DO ever compiled (and keep track of which loopsys is current during compilation, for example using the control or return stack)? This would of course (permanently) waste data space, compared to the "normal" way of (temporarily) consuming return-stack space.

AntonErtl [r1173] 2024-01-22 09:56:20

Such an implementation would be standard.

Conceptually system-internal data generated during compilation is not part of data space even if it is interleaved with data space data (at least parts of the standard handle it this way; not sure if the standard is consistent here).

Closed

ruv [r1185] 2024-01-31 12:35:34

Would it be conforming for an implementation to generate a new loopsys in data space for every DO ever compiled

Usually, a loop-sys is created in run-time.

An implementation may allocate data space while performing the compilation semantics for DO, but it is not allowed to allocate data space while performing the run-time semantics for DO.

If you allocate a slot for loop-sys at compile time, it will not work correctly in run-time when recursion occurs (directly or indirectly) — the slot will be overwritten and not restored.

lmr [r1193] 2024-01-31 20:37:24

If you allocate a slot for loop-sys at compile time, it will not work correctly in run-time when recursion occurs (directly or indirectly) — the slot will be overwritten and not restored.

That's it. This means DO introduces the equivalent of subroutine-local variables, which must be stored on the "call stack" (return stack in Forth) for recursion to work, just like in other languages.

Reply New Version