Menu
▾
▴
tiny-cobol-users
|
From: Rildo P. <rpr...@ac...> - 1999-12-06 16:32:43
|
Hi Jim,
On Mon, 6 Dec 1999, Noeth, Jim wrote:
> 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.
Your'e right, the field "decimals" refer to the number of decimals to the
right (if positive), or the number of zeros to add at the right if
negative, in this case as an absolute value, when the clause have "P" at
the right. So it is the scaling of the field.
You don't need to scan the picture to get this.
> 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?
The "all" means whe shall "wrap around" when reaching the last position of
a literal, because it should be repeated. For instance to move "ABC" with
"all = 1" to a field with size 10, will give "ABCABCABCA". The size of
the first field (that must be a literal, of course) is 3.
> How do we want to handle run time errors, such as moving non numeric data
> into a numeric field?
Well, I'm no cobol guru. There are many of them in this list, so I'll let
one of them answer your question :)
regards,
_____ _ __ __ __ __ ___ __ Rildo Pragana
/\ '__`\/\`'__\/'__`\ /'_ `\ /'__`\ /' _ `\ /'__`\ P.O. Box 721
\ \ \L\ \ \ \//\ \L\.\_/\ \L\ \/\ \L\.\_/\ \/\ \/\ \L\.\_ Camaragibe
\ \ ,__/\ \_\\ \__/.\_\ \____ \ \__/.\_\ \_\ \_\ \__/.\_\ PE Brazil
\ \ \/ \/_/ \/__/\/_/\/___L\ \/__/\/_/\/_/\/_/\/__/\/_/ 54792-990
\ \_\ rpr...@ac... /\____/ FPGA/uControllers * Linux * tcl/tk
\/_/ +55-81-459-1776 \_/__/ http://members.xoom.com/rpragana/
|
|
From: Glen C. <gco...@US...> - 1999-12-07 02:37:17
|
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
|
|
From: Glen C. <gco...@US...> - 1999-12-07 02:46:30
|
>
> > How do we want to handle run time errors, such as moving non
> > numeric data into a numeric field?
I would like to see a runtime error routine that
1) Text and numeric description of documented error
2) Hex and ascii dump of all storage areas, identified by storage area
WORKING-STORAGE
EF 23 42 4F 7B 28 ...FOE.
74 00 00 00 00 00 FE.....
LINKAGE-1
F0 F0 F0 F0 F0 F0 .....
31 31 31 31 31 31 11111
3) Text information of compiled file name (from PROGRAM-ID ??)
4) Compiler version information
5) Program compile date and time
6) Source code LINE NUMBER of offending statement
6a) Token number on offending line ??
Being as I want so much, I probably should write this =:()
Glen
|
|
From: Noeth, J. <jm...@ag...> - 1999-12-08 13:35:00
|
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
>
|
|
From: Glen C. <gco...@US...> - 1999-12-09 03:43:09
|
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
Jim,
In 15 years, I've used it a total of twice (interest computation
intermediate fields on foreign currencies)
Glen
|
|
From: Rildo P. <rpr...@ac...> - 1999-12-08 15:43:31
|
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
|
|
From: Noeth, J. <jm...@ag...> - 1999-12-08 17:30:24
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X