RE: [Tiny-cobol-users] Runtime Move Routine questions

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

To all,

I was out yesterday, and just finished reading all my email from yesterday.
I'll respond to multiple email messages in this message.

First, a response to the message from Glen. I have used the ALL modifier and
am familiar with it, but am not familiar with the 'P' in the picture clause
(in 25 years of COBOL programming, I've never run accross it). I got the
book out and looked at all the various ways a picture clause can be
constructed, and I as such, I would like to add a precision field to the
fld_desc structure. This new field would contain the number (positive) of
'P' characters on the right side of the picture clause, and the negative of
the number of 'P' characters on the left side of the picture clause. I would
also like to add one additional field to the structure that would be zero if
the field being described was unsigned, and non zero if the field is signed.

Also, as for handling run time errors, I would like to propose the following
calling convention:

        void runtime_error(int iErrorNbr, struct fld_desc *pFldDesc, void
*pData);

Where iErrorNbr is a standard set of error numbers (we can use this to
obtain text to go along with the number). To get things moving along, we can
just write a stub routine, which can be extended later. I (like Glen) would
also like to see things like file name of the source file (which is pretty
easy) and the line number of the offending statement, but I don't know if
that data is easily obtainable at runtime.

I would be interested in writing the math routines (multiply, add, etc.)
when I'm finished with the move routines, if no one else has started it by
then.

My last thing is a suggestion, which I realize may be a slight departure
from the way that the compiler has been developed. The suggestion is that
rather than building x86 assembly language straight out of the compiler,
that the compiler generate a relatively simple psuedo code, which can then
be translated into x86 assembly language. The reason is that porting the
compiler for a different processor is then made much easier,  just write a
new pseudo code translator for the new processor. Parsing the pseudo code
should be much simpler than parsing a complex language like COBOL.

Jim Noeth


> -----Original Message-----
> From:	Glen Colbert [SMTP:gco...@US...]
> Sent:	Monday, December 06, 1999 6:37 PM
> To:	tin...@so...
> Subject:	RE: [Tiny-cobol-users] Runtime  Move Routine questions
> 
> Jim,
>   All is a special case.  It should move repeating copies of the source to
> the target.  This does not happen if the ALL modifier is not used.
>  
>   Just a note.  The decimal point can be either to the left or to the
> right of significant digits.
>  
> PIC 999V99
> PIC VPPP999
> PIV 999PPV
> 
> 	-----Original Message-----
> 	From: tin...@so...
> [mailto:tin...@so...]On Behalf Of Noeth, Jim
> 	Sent: Monday, December 06, 1999 9:06 AM
> 	To: 'tin...@li...'
> 	Subject: [Tiny-cobol-users] Runtime Move Routine questions
> 	
> 	
> 
> 	I am currently working on the run time routines that perform move
> related functions. I have run into a few situations that I would like
> input on.
> 
> 	It appears that the decimals field of the fld_desc structure is
> being used as a boolean value to indicate whether or not there are digits
> to the right of the decimal point. If this field contained the number of
> digits to the right of the decimal point instead and an indicator was
> added to the structure as to whether or not this was a signed field, the
> runtime routines could be made much more efficient, as they would not have
> to decode the picture clause, except for editted fields. 
> 
> 	The 'all' field of the fld_desc structure (which is documented in
> the info section as occurs) is used to signify that the data associated
> with the field, when moved to another field will be repeated until the
> length of the receiving field is satisfied. Which definition is correct,
> or do we need both?
> 
> 	How do we want to handle run time errors, such as moving non numeric
> data into a numeric field? 
> 
> 	Thanks, 
> 	Jim Noeth 
>