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

[Rildo P. <rpr...@ac...>]

Hi Jim,

On Wed, 8 Dec 1999, Noeth, Jim wrote:

> 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.

Please look at this program fragment, taken from our compiler listings,
and you will see that you don't need more variables in the fld_desc structure:

0014:       WORKING-STORAGE SECTION.
0015:       01 VAR1    PIC 9999V999.
0016:       01 VAR2    PIC VPP9.
0017:       01 VAR3    PIC 999PPPP.
0018:
                                     vvvvvvv
-------------------------------------------------+---------------
Symbol ( Variables )      Type Level Len Dec Mul | Desc Loc  Pic
-------------------------------------------------+---------------
                      VAR1   9     1   7   3   1 | 0000 0007 000B
                      VAR2   9     1   1   3   1 | 0012 0008 001D
                      VAR3   9     1   3  -4   1 | 0024 000B 002F
									 ^^^^^^^
									   
The fields "Len" and "Dec" can give you the full information about scaling the
number.  The first (VAR1) have 3 decimal digits. The second also, but only 1
char in length, so it must be after the decimal point (of course).  The third
(with a negative "Dec" value) tell us that we have "to shift the decimal point"
to the right 4 digits, or we have to scale it by 10000.
Each "P" means a shift in the decimal point but don't reserve storage for the
digit. Play around with the compiler to look what those variables generate.

The fld_desc equivalents are:  fld_desc->len for "Len" above, and
fld_desc->decimals for "Dec" above.

> 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.

Well, I hope to have å better picture of this, so I can understand what you
mean.  If you just want the runtime to generate the source line with the
problem, there is another way to generate it.
 
> 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.

We already have both "move" and arithmetic routines.  The first one is very
buggy. That's why I suggested it to be redone.  The arith functions we can do
them again if we plan to change it to a multi-precision library (like gmp).
They are working converting the numbers to/from double floats.

> 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.

Perhaps we should generate C instead (the best intermediate language!), but
this means a complete redesign of our code generator.  I have done already the
first steps, but let us leave this to a future release.  We must first have
this thing working according the standard cobol'74.  Then we can think of
improvements and portings.

best regards,
Rildo
 ----------------------------------------------------------------
 Rildo Pragana                 FPGA/uControllers * Linux * tcl/tk
 P.O. Box 721 Camaragibe PE    http://members.xoom.com/rpragana
 Brazil 54792-990              +55-81-459-1776