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

[Noeth, J. <jm...@ag...>]

Glen (and others who commented on the move routines)

Thanks for the feedback. I am using a 7 by 7 matrix to determine which type
of move to generate (The compiler doesn't currently support all possible
data types, but it probably will in the future). This results in 49 possible
move types, although a number of them are illogical (such as moving an
numeric edited field to a packed decimal field). I have started by defining
each of this in a large case statement, so each of the move types does stand
alone, but is all inline code as opposed to individual routines. Making
individual routines out of them is a good idea, though, I will pursue that.

My intent was to build the code for the move verb inline, as opposed to
calling a routine to execute the move. This will result in a larger
executable, but will not incur the overhead of pushing arguments onto the
stack and calling a subroutine.

By the way, the matrix is made  up of the following source/destination types
(although not all are currently supported):

Alpha/Alpha Numeric (no distinction is made)
Binary Integer 
Display (numeric)
Editted Alpha
Editted Numeric
Floating Point
Packed Decimal

Jim Noeth 

> -----Original Message-----
> From:	Glen Colbert [SMTP:gco...@us...]
> Sent:	Monday, December 13, 1999 6:36 PM
> To:	tin...@so...
> Subject:	RE: [Tiny-cobol-users] (no subject)
> 
> > -----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
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Tiny-cobol-users mailing list
> Tin...@li...
> http://lists.sourceforge.net/mailman/listinfo/tiny-cobol-users