RE: [Tiny-cobol-users] (no subject)

[Glen C. <gco...@US...>]

> -----Original Message-----
> From: tin...@so...
> [mailto:tin...@so...]On Behalf Of Noeth, Jim
> Sent: Monday, December 13, 1999 10:00 AM
> To: 'tin...@li...'

> 'gen_move'
> routine to generate the code directly, all of the information to do these
> 'overhead' calculations is available at compile time, and we
> could generate
> code that is very specific to each move statement.

Hi Jim,

  I think that the most supportable approach (in the long term) would be a
routine for each source/target combination.  This would result in about
28-40 different move commands (depending on the number of numeric types that
we define).  While this is a LOT more to program, it will allow individual
tuning and troubleshooting.

  You should also consider that these move types are closely related to the
math routines.....and each math routine will probably end by calling a move
to move the data from a math library variable (FPU register, GNU Infinite
Math type, or whatever) to numeric and/or numeric edited fields.  Additional
consideration may be needed for constants (MOVE -123.45 TO WS-NUMBER) as
these seem to be treated differently by the compiler (what data type should
we assign constants to)...

  To permit multiple programmers to work in the move libraries without
tripping on each other, we should probably divide the move library into
seperate source code based either on source or target data type (math would
be easier if we divided by source, edited field moves would be easier if we
divided by destination type).

  A nice feature would be to only link in the move code used by the program
(multiple move and math libraries?), but this is probably overkill.

Glen