Follow-up to Buck's /FREE comments

>From Buck:
<snip>
> Although I like talking about the kibbles & bits of this stuff as much
> as anyone else, I've come to the realisation that there is a growing
> issue with the omission of MOVE & friends that hasn't quite been
> touched upon yet.  With enhancements being made to /free and not to
> fixed-format, there will be increasing pressure to _convert_ large
> blocks of existing code, rather than simply write new, small blocks
> (functions) in /free.  I doubt there's any tool aside from the
> compiler itself which can reasonably figure out what combination of
> BIFs to substitute in place of MOVE.
</snip>

Many downstream programmers can't figure out the intent of a given line of
code, and I'm not sure the compiler can do any better.

Thinking and working in /FREE while having to duck into and out of
fixed-format because of compiler support deficiencies will make code
conversion cumbersome to the point of unacceptability.

The view of many FF programmers is that /FREE is flawed because the long
list of unsupported opcodes; this is a big factor in the slow acceptance of
/FREE.  IBM has provided a workaround (/END-FREE) but I believe that
tarnishes IBM's commitment to the language.

Providing %MOVE, %MOVEA, and %MOVEL BIF's, working /exactly/ like their FF
counterparts, solves one problem often faced by downstream programmers
working on legacy code.  

The Programming Police must be sitting on a /FREE GOTO; I can't imagine a
technical barrier....and let's make sure we have a /FREE TAG too!  I may
convert a program to /FREE for any number of reasons; eliminating GOTO's
won't be one of them and refactoring isn't in scope.

I'm not suggesting a degradation of /FREE.  I'd just like to see the basics
completed sooner rather than later.

-reeve