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

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

Rildo,

Thanks for the explanation of the 'P' stuff, makes sense now.

Jim Noeth=20
> -----Original Message-----
> From:	Rildo Pragana [SMTP:rpr...@ac...]
> Sent:	Wednesday, December 08, 1999 9:46 AM
> To:	'tin...@so...'
> Subject:	RE: [Tiny-cobol-users] Runtime  Move Routine questions
>=20
> Hi Jim,
>=20
> On Wed, 8 Dec 1999, Noeth, Jim wrote:
>=20
> > I was out yesterday, and just finished reading all my email from
> yesterday.
> > I'll respond to multiple email messages in this message.
> >=20
> > 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.
>=20
> 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:
>=20
> 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
> =09
> ^^^^^^^
> 									  =20
> 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.
>=20
> The fld_desc equivalents are:  fld_desc->len for "Len" above, and
> fld_desc->decimals for "Dec" above.
>=20
> > Also, as for handling run time errors, I would like to propose the
> following
> > calling convention:
> >=20
> >         void runtime_error(int iErrorNbr, struct fld_desc =
*pFldDesc,
> void
> > *pData);
> >=20
> > 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.
>=20
> Well, I hope to have =E5 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.
> =20
> > 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.
>=20
> > 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.
>=20
> 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.
>=20
> 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
>=20
>=20
> _______________________________________________
> Tiny-cobol-users mailing list
> Tin...@li...
> http://lists.sourceforge.net/mailman/listinfo/tiny-cobol-users