cobolforgcc-devel Mailing List for Cobol for GCC (Page 5)
Status: Pre-Alpha
Brought to you by:
timjosling
Menu
▾
▴
cobolforgcc-devel — For discussion about development of COBOL for GCC
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(20) |
Sep
(2) |
Oct
(4) |
Nov
(16) |
Dec
(15) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(13) |
Feb
(5) |
Mar
(21) |
Apr
(34) |
May
(9) |
Jun
(22) |
Jul
|
Aug
(6) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(24) |
Jul
(1) |
Aug
|
Sep
(4) |
Oct
(6) |
Nov
|
Dec
(1) |
| 2003 |
Jan
(2) |
Feb
|
Mar
|
Apr
(11) |
May
(19) |
Jun
(2) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2008 |
Jan
(15) |
Feb
(4) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Steven O. E. <so...@so...> - 2001-09-09 19:21:28
|
Tim,
I have gone back to the idea of inner loops and thought about it a bit.
It seems to me that keeping track of the all the possibilities, some of
which might involve backtracking, might make the "loops solution"
just as complex as the linear solution I am working on. I'll know
more when I run a few tests.
There a couple more questions regarding the function arguments
that I would like to get resolved before I spend too much more time
setting up the tests.
1) Many options to UNSTRING are optional. I have assumed in
my coding that if an array of options, like "count_in_array" or
"delimiter_in_array" is not used, then it is passed as a NULL
pointer. Is that how you understand it?
Further, that if even one such field is used, then the array
must be fully instantiated, that is, space must be allocated on
the heap for the entire array, whether it is all needed or not,
and when UNSTRING returns, the core compiler will simply
pick out those elements that were actually specified by the
COBOL programmer.
For example, if the fifth target item is the only one that has
COUNT IN specified, then the count_in_array argument to
UNSTRING must be a pointer to a space big enough for the
whole array. If no target items have COUNT IN, then the
count_in_array argument can be NULL.
That is, if the count_in_array or the delimiter_in_array
arguments are NULL, the UNSTRING function ignores them.
If not, UNSTRING populates all of the elements and the
core compiler can pick out the ones it needs.
2) If the above seems right to you, then I wonder if the
TALLYING field should be made a pointer than can be
NULL if the field is not specified.
3) I am assuming that the POINTER field is always going
to be passed (as an int) to the UNSTRING function.
Thanks,
Steven
Tim Josling wrote:
> Steven,
>
> I tend to think the best way might be to do it in a quite simple manner
> ie with the inner loops. Most unstrings I have seen have only had one or
> a small number of short delimiters. The Extreme Programming term for this
> is 'The Simplest Thing That Could Possibly Work'.
>
> As far as the data types go, the receiving area must be display but can
> be numeric (with all the usual overpunching stuff) and can be right
> justified as well as left justified.
>
> The core compiler does not support numeric display or right justified
> yet, so support for these is not urgent and there is no runtime routine
> to do it yet. My thought would be to support right justified in your own
> code. When I add right justified to the compiler I will pull that code
> out into its own routine. But I would just put an abort in if you get a
> numeric display format output item. We could add that support later on
> quite easily, as a call to the appropriate move routine.
>
> My preference always is to get something working and then refine it,
> rather than solve all the problems at once. But go with the approach you
> are most comfortable with.
>
> Tim Josling
>
> "Steven O. Ellis" wrote:
>
> > Tim,
> >
> > I set up several designs for test cases and coded a few of them.
> > Then I decided to go back and actually start coding the UNSTRING
> > routine. Whew! Nontrivial.
> >
> > The problem lies in preventing excessive looping when the user
> > (COBOL programmer) specifies several, long delimiters. There is
> > a risk of having to set up the problem all over again, one byte at a
> > time, when several delimiters are matching up to a point and then
> > failing, causing the algorithm has to have to backtrack over and over.
> >
> > In order to handle this, I am exploring the Knuth-Morris-Pratt
> > algorithm as discussed in "Introduction to Algorithms", by
> > Cormen, Leiserson, and Rivest (c) 1990 MIT. I have this coded
> > but not yet tested. A slight modification to the KMP algorithm
> > would seem to allow the delimiter-check to ride along the source
> > field in a linear fashion, without backtracking, even with multiple
> > length delimiters.
> >
> > This brings up a few questions. I have no compiler-writing
> > training, and I'm not familiar with your overall design, so perhaps
> > we can discuss this.
> >
> > We talked about MOVE awhile back but I don't think I ever
> > directly asked this: can UNSTRING call the
> > MOVE routine, or must it be coded within UNSTRING itself? If
> > MOVE has been coded and is available, I would like to have the
> > source and headers. If not coded but the call is OK, I will put in
> > a temporary function. If the call is not OK, I will code the move
> > into the UNSTRING function itself.
> >
> > Speaking of function calls, is UNSTRING allowed to call another
> > function at all? The KMP algorithm is best implemented as two
> > functions. One I am coding into UNSTRING itself, but the initial
> > setup should be done by a function called by UNSTRING.
> > Is this OK?
> >
> > If it is OK to use a separate function for setting up the algorithm,
> > then I have another question about how the compiler deals with
> > this, but I'll wait until I hear back from you.
> >
> > Steven
> >
> > _______________________________________________
> > Cobolforgcc-devel mailing list
> > Cob...@li...
> > http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel
>
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel
|
|
From: Tim J. <te...@me...> - 2001-08-30 08:34:43
|
This was contribued by Linga Ramakrishna. Thanks, Tim Josling |
|
From: Tim J. <te...@me...> - 2001-08-28 22:15:51
|
Steven, I tend to think the best way might be to do it in a quite simple manner ie with the inner loops. Most unstrings I have seen have only had one or a small number of short delimiters. The Extreme Programming term for this is 'The Simplest Thing That Could Possibly Work'. As far as the data types go, the receiving area must be display but can be numeric (with all the usual overpunching stuff) and can be right justified as well as left justified. The core compiler does not support numeric display or right justified yet, so support for these is not urgent and there is no runtime routine to do it yet. My thought would be to support right justified in your own code. When I add right justified to the compiler I will pull that code out into its own routine. But I would just put an abort in if you get a numeric display format output item. We could add that support later on quite easily, as a call to the appropriate move routine. My preference always is to get something working and then refine it, rather than solve all the problems at once. But go with the approach you are most comfortable with. Tim Josling "Steven O. Ellis" wrote: > Tim, > > I set up several designs for test cases and coded a few of them. > Then I decided to go back and actually start coding the UNSTRING > routine. Whew! Nontrivial. > > The problem lies in preventing excessive looping when the user > (COBOL programmer) specifies several, long delimiters. There is > a risk of having to set up the problem all over again, one byte at a > time, when several delimiters are matching up to a point and then > failing, causing the algorithm has to have to backtrack over and over. > > In order to handle this, I am exploring the Knuth-Morris-Pratt > algorithm as discussed in "Introduction to Algorithms", by > Cormen, Leiserson, and Rivest (c) 1990 MIT. I have this coded > but not yet tested. A slight modification to the KMP algorithm > would seem to allow the delimiter-check to ride along the source > field in a linear fashion, without backtracking, even with multiple > length delimiters. > > This brings up a few questions. I have no compiler-writing > training, and I'm not familiar with your overall design, so perhaps > we can discuss this. > > We talked about MOVE awhile back but I don't think I ever > directly asked this: can UNSTRING call the > MOVE routine, or must it be coded within UNSTRING itself? If > MOVE has been coded and is available, I would like to have the > source and headers. If not coded but the call is OK, I will put in > a temporary function. If the call is not OK, I will code the move > into the UNSTRING function itself. > > Speaking of function calls, is UNSTRING allowed to call another > function at all? The KMP algorithm is best implemented as two > functions. One I am coding into UNSTRING itself, but the initial > setup should be done by a function called by UNSTRING. > Is this OK? > > If it is OK to use a separate function for setting up the algorithm, > then I have another question about how the compiler deals with > this, but I'll wait until I hear back from you. > > Steven > > _______________________________________________ > Cobolforgcc-devel mailing list > Cob...@li... > http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel |
|
From: Steven O. E. <so...@so...> - 2001-08-26 20:12:20
|
Tim, I set up several designs for test cases and coded a few of them. Then I decided to go back and actually start coding the UNSTRING routine. Whew! Nontrivial. The problem lies in preventing excessive looping when the user (COBOL programmer) specifies several, long delimiters. There is a risk of having to set up the problem all over again, one byte at a time, when several delimiters are matching up to a point and then failing, causing the algorithm has to have to backtrack over and over. In order to handle this, I am exploring the Knuth-Morris-Pratt algorithm as discussed in "Introduction to Algorithms", by Cormen, Leiserson, and Rivest (c) 1990 MIT. I have this coded but not yet tested. A slight modification to the KMP algorithm would seem to allow the delimiter-check to ride along the source field in a linear fashion, without backtracking, even with multiple length delimiters. This brings up a few questions. I have no compiler-writing training, and I'm not familiar with your overall design, so perhaps we can discuss this. We talked about MOVE awhile back but I don't think I ever directly asked this: can UNSTRING call the MOVE routine, or must it be coded within UNSTRING itself? If MOVE has been coded and is available, I would like to have the source and headers. If not coded but the call is OK, I will put in a temporary function. If the call is not OK, I will code the move into the UNSTRING function itself. Speaking of function calls, is UNSTRING allowed to call another function at all? The KMP algorithm is best implemented as two functions. One I am coding into UNSTRING itself, but the initial setup should be done by a function called by UNSTRING. Is this OK? If it is OK to use a separate function for setting up the algorithm, then I have another question about how the compiler deals with this, but I'll wait until I hear back from you. Steven |
|
From: Tim J. <te...@me...> - 2001-08-20 20:21:58
|
Bill, I accept the standard code. I do not give a warning about next sentence within end-if but I have a FIXME in the code to add that later. There warnings will be as you say. Tim Josling "William M. Klein" wrote: > Tim, > Have you included the "correct" code for NEXT SENTENCE and END-IF, e.g. |
|
From: William M. K. <wm...@ix...> - 2001-08-19 23:34:34
|
Tim,
Have you included the "correct" code for NEXT SENTENCE and END-IF, e.g.
Program that should compile and run 'as expected'
Identification Division.
Program-Id. ShouldCompile.
Data Division.
Working-Storage Section.
01 Always-A Pic X Value "A".
01 Test-a-Field Pic 9(06).
Procedure Division.
Mainline.
Accept Test-A-Field from Date
If Test-A-field (1:2) >= 50
If Always-A = "A"
Next Sentence
Else
Continue
Else
Display "< 50"
End-If
*> End-IF *is* allowed as the NEXT SENTENCE is in a nested IF
Stop Run
.
Versus the following Program that should NOT compile (or should get a
non-Standard flagging message)
Identification Division.
Program-Id. ShouldNotCompile.
Data Division.
Working-Storage Section.
01 Always-A Pic X Value "A".
01 Test-a-Field Pic 9(06).
Procedure Division.
Mainline.
Accept Test-A-Field from Date
If Test-A-field (1:2) >= 50
Next Sentence
Else
Display "< 50"
End-If
*> End-If cannot be used with an IF that has NEXT SENTENCE
Stop Run
.
> -----Original Message-----
> From: cob...@li...
> [mailto:cob...@li...]On Behalf Of Tim
> Josling
> Sent: Saturday, August 18, 2001 10:54 PM
> To: cobolforgcc-devel
> Subject: [Cobolforgcc-devel] IF is now working.
>
>
> I've completed the testing of IF and checked it in.
|
|
From: Tim J. <te...@me...> - 2001-08-19 03:57:39
|
I've completed the testing of IF and checked it in. Next is PERFORM, then CALL/etc. That will complete the initial subset. Tim Josling |
|
From: Tim J. <te...@me...> - 2001-06-27 20:22:54
|
Piet, Yes you are correct. Don't believe everything I say ;-). So yes go ahead with convert to uppper case. Would you mind replying via the list so that way we have a record of the discussions. I have added you to the project assigned the task to you. Note someone else had volunteered to do this a long time ago but it has not happened so you own it now. Tim Josling > "Wiid, P. (Piet)" wrote: > > Dear Tim, > Thanks for your note. > > I have registered at Sourceforge, and my userid is pietwiid > > I have looked at the code and I think it is the code for the > 'convert to lower case' routine. I assume you need the 'convert > to upper case' routine. > > I am in the meantime continuing assuming I have to create the > 'convert to upper case'. > > Regards, > Piet Wiid. > pi...@ne... |
|
From: Tim J. <te...@me...> - 2001-06-25 10:04:43
|
Thank Steven, I will check it out, Tim Josling "Steven O. Ellis" wrote: > > There is a mention of the CobolforGCC project in the Letters section of > the July 2001 Dr. Dobb's Journal, which came out in early June. I know > because I wrote it. :)) > > _______________________________________________ > Cobolforgcc-devel mailing list > Cob...@li... > http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel |
|
From: Tim J. <te...@me...> - 2001-06-25 09:49:04
|
Bill, Thanks. It is in the todo list. Tim Josling "William M. Klein" wrote: > > Tim, > I FULLY understand doing "conforming" support first, but I thought I would > point you to some documentation on some IBM extensions for compound IF > statements (and some differences > - between OS/VS COBOL and newer COBOLs > - between '68 and '74 Standard COBOL. > > Look at: > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGYMG202/4.1.7 > > and go down to the sections: > > Combined abbreviated relation condition changes > > and > > IF...OTHERWISE statement changes > > and > > Numeric class test on group items > > and also look at: > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGYMG202/4.1.6 > > and go down to > > Abbreviated combined relation conditions and use of parentheses > > and > > Comparing group to numeric packed-decimal item > > *** > > Some of these are in PRETTY common use among IBM COBOL programmers (and > compiler vendors who implement "compatibility" for IBM such as CA-Realia and > Micro Focus (MERANT). > > NONE of them should be "higher priority" than the conforming stuff, but I > did want to at least alert you to this stuff. > > > -----Original Message----- > > From: cob...@li... > > [mailto:cob...@li...]On Behalf Of Tim > > Josling > > Sent: Saturday, June 23, 2001 10:17 PM > > To: cobolforgcc-devel > > Subject: [Cobolforgcc-devel] IF half done > > > > > > I have uploaded the changes so far to support IF (incomplete), > > and I also reformatted the code to meet the gcc coding standards > > - Kiesuke poitned out some divergences. > > Tim Josling > > > > _______________________________________________ > > Cobolforgcc-devel mailing list > > Cob...@li... > > http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel > > _______________________________________________ > Cobolforgcc-devel mailing list > Cob...@li... > http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel |
|
From: William M. K. <wm...@ix...> - 2001-06-25 00:16:57
|
Tim, I FULLY understand doing "conforming" support first, but I thought I would point you to some documentation on some IBM extensions for compound IF statements (and some differences - between OS/VS COBOL and newer COBOLs - between '68 and '74 Standard COBOL. Look at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGYMG202/4.1.7 and go down to the sections: Combined abbreviated relation condition changes and IF...OTHERWISE statement changes and Numeric class test on group items and also look at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGYMG202/4.1.6 and go down to Abbreviated combined relation conditions and use of parentheses and Comparing group to numeric packed-decimal item *** Some of these are in PRETTY common use among IBM COBOL programmers (and compiler vendors who implement "compatibility" for IBM such as CA-Realia and Micro Focus (MERANT). NONE of them should be "higher priority" than the conforming stuff, but I did want to at least alert you to this stuff. > -----Original Message----- > From: cob...@li... > [mailto:cob...@li...]On Behalf Of Tim > Josling > Sent: Saturday, June 23, 2001 10:17 PM > To: cobolforgcc-devel > Subject: [Cobolforgcc-devel] IF half done > > > I have uploaded the changes so far to support IF (incomplete), > and I also reformatted the code to meet the gcc coding standards > - Kiesuke poitned out some divergences. > Tim Josling > > _______________________________________________ > Cobolforgcc-devel mailing list > Cob...@li... > http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel |
|
From: Steven O. E. <so...@so...> - 2001-06-24 15:07:59
|
There is a mention of the CobolforGCC project in the Letters section of the July 2001 Dr. Dobb's Journal, which came out in early June. I know because I wrote it. :)) |
|
From: Tim J. <te...@me...> - 2001-06-24 03:24:59
|
I have uploaded the changes so far to support IF (incomplete), and I also reformatted the code to meet the gcc coding standards - Kiesuke poitned out some divergences. Tim Josling |
|
From: Tim J. <te...@me...> - 2001-06-19 20:38:51
|
James, Yes I am still working on it. I am half way through doing 'IF' at the moment. Threee places to start: 1. http://gcc.gnu.org has a 'readings' link. The GCC manual is also there. 2. The new 'treelang' language which is at http://cobolforgcc.sourceforge.net/butree.tgz. IMHO this is a much better 'toy' language. It is plaanned to include it into the GCC source tree soon. 3. The COBOL complier manual has a guide on writing front ends at http://cobolforgcc.sourceforge.net/cobol_14.html. Good luck! Tim Josling James wrote: > > Hi, > > Are you still working on the COBOL frontend for GCC? > > I just thought I'd mail and pester you about the best possible place to > start the long journey to enlightenment; i.e. where to start to write a > new frontend for GCC. > > Is that toy language the best place to start? I hear that GCC has a > fairly complex inner language (for ??) Where can I find out what I need > to implement a front end for a new language? > > With thanks, > James > > --- > James Buchanan > Muli Management Pty Ltd > js...@mu... |
|
From: Tim J. <te...@me...> - 2001-06-12 22:53:52
|
Matthew, I would prefer to leave out anything that is not in the COBOL 85 standard at this stage. Building a cobol 85 compiler is big enough. I have had my fingers burned in the past doing extensions. If you do add any other features, please make sure it does not break any legal cobol 85 programs (eg by adding new keywords that cannot be turned off). Tim Josling Matthew Vanecek wrote: > > On 11 Jun 2001 13:53:04 -0500, William M. Klein wrote: > > FYI - even in the draft COBOL Standard "file-sharing/record-locking" is in > > the Processor Dependent list. Therefore, I would suggest (?) that it be > > placed in the "later" category, and that any work on 200x features > > concentrate on those features that are REQUIRED (at least first). > > > > Very true, and I will be marking much as RSN. I just wanted to get the > grammar itself as complete as possible. > -- > Matthew Vanecek > perl -e 'print > $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' > ******************************************************************************** > For 93 million miles, there is nothing between the sun and my shadow > except me. > I'm always getting in the way of something... > > _______________________________________________ > Cobolforgcc-devel mailing list > Cob...@li... > http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel |
|
From: Matthew V. <lin...@ho...> - 2001-06-12 01:15:08
|
On 11 Jun 2001 13:53:04 -0500, William M. Klein wrote: > FYI - even in the draft COBOL Standard "file-sharing/record-locking" is in > the Processor Dependent list. Therefore, I would suggest (?) that it be > placed in the "later" category, and that any work on 200x features > concentrate on those features that are REQUIRED (at least first). > Very true, and I will be marking much as RSN. I just wanted to get the grammar itself as complete as possible. -- Matthew Vanecek perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' ******************************************************************************** For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something... |
|
From: William M. K. <wm...@ix...> - 2001-06-11 18:53:08
|
FYI - even in the draft COBOL Standard "file-sharing/record-locking" is in
the Processor Dependent list. Therefore, I would suggest (?) that it be
placed in the "later" category, and that any work on 200x features
concentrate on those features that are REQUIRED (at least first).
> -----Original Message-----
> From: cob...@li...
> [mailto:cob...@li...]On Behalf Of Tim
> Josling
> Sent: Sunday, June 10, 2001 9:42 PM
> To: cob...@li...
> Subject: Re: [Cobolforgcc-devel] yacc/bison question
>
>
> Matthew,
>
> Good to hear from you.
>
> There is no LOCK MODE in COBOL 85, so you can just omit it (for
> now). It is only in COBOL 2002.
>
> The problem appears to be due to the fact that the LOCK could be
> the start of a LOCK ON MULTIPLE or the start of a second
> occurrence of the LOCK MODE clause.
>
> You basically have the right answer. Function set_up_magic_tokens
> will need to be updated to change the first LOCK to a magic token
> like LOCK_magic_starts_whole_clause. The logic for this would be
> if it is not followed by ON, RECORD or RECORDS it must be the
> first one.
>
> If this makes no sense, please send me *all* the files.
>
> Are you in a position to do a copyright assignment to the free
> software foundation for this work. I will attach the files which
> explain it all. Without the assignments we will not be able to
> have the compiler incorporated into the official GCC. Please have
> a look.
>
> Tim Josling
>
> Matthew Vanecek wrote:
> >
> > Tim,
> > I was working on my file i/o grammar this weekend, and ran into some
> > issues with the LOCK MODE clause. I've kinda got it figured out, but
> > I'm not certain that it's the correct way:
> >
> > I've got a clause:
> >
> > LOCK [MODE IS] {MANUAL | AUTOMATIC} [[WITH] LOCK ON {RECORD | RECORDS}]
> >
> > The two LOCKs were causing reduce/reduce errors. I finally ended up
> > sticking a "LOCK_ON" token in cobctok.def to alleviate the ambiguity for
> > bison/yacc. I'm a little worried about the kvalue, however. I've set
> > it to "LOCK ON". I'd like to figure out a way to delete that token, and
> > still not have any shift/reduce or reduce/reduce errors.
> >
> > Here's the relevant bit from my file.tpl:
> >
> > lock_mode_clause:
> > LOCK opt_mode opt_is manual_or_auto_kw opt_lock_on_clause {
> > RSN($1, "Lock Mode not yet supported");
> > }
> > ;
> >
> > manual_or_auto_kw:
> > MANUAL
> > | AUTOMATIC
> > ;
> >
> > opt_lock_on_clause:
> > /* nothing */
> > | with_lock_on
> > ;
> >
> > with_lock_on:
> > opt_with lock_on
> > ;
> >
> > lock_on:
> > LOCK_ON record_or_records
> > ;
> >
> > record_or_records:
> > RECORD
> > | RECORDS
> > ;
> >
> > If I change the "LOCK_ON" to "LOCK ON", I get a reduce/reduce error. I
> > would rather not have any errors, but I'm still a little dubious about a
> > "LOCK_ON" token.
> >
> > Thoughts?
> > --
> > Matthew Vanecek
> > perl -e 'print
> > $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
> >
> ******************************************************************
> **************
> > For 93 million miles, there is nothing between the sun and my shadow
> > except me.
> > I'm always getting in the way of something...
> >
> > -----------------------------------------------------------------
> > Part 1.2Type: application/pgp-signature
|
|
From: Tim J. <te...@me...> - 2001-06-11 02:49:55
|
Matthew,
Good to hear from you.
There is no LOCK MODE in COBOL 85, so you can just omit it (for
now). It is only in COBOL 2002.
The problem appears to be due to the fact that the LOCK could be
the start of a LOCK ON MULTIPLE or the start of a second
occurrence of the LOCK MODE clause.
You basically have the right answer. Function set_up_magic_tokens
will need to be updated to change the first LOCK to a magic token
like LOCK_magic_starts_whole_clause. The logic for this would be
if it is not followed by ON, RECORD or RECORDS it must be the
first one.
If this makes no sense, please send me *all* the files.
Are you in a position to do a copyright assignment to the free
software foundation for this work. I will attach the files which
explain it all. Without the assignments we will not be able to
have the compiler incorporated into the official GCC. Please have
a look.
Tim Josling
Matthew Vanecek wrote:
>
> Tim,
> I was working on my file i/o grammar this weekend, and ran into some
> issues with the LOCK MODE clause. I've kinda got it figured out, but
> I'm not certain that it's the correct way:
>
> I've got a clause:
>
> LOCK [MODE IS] {MANUAL | AUTOMATIC} [[WITH] LOCK ON {RECORD | RECORDS}]
>
> The two LOCKs were causing reduce/reduce errors. I finally ended up
> sticking a "LOCK_ON" token in cobctok.def to alleviate the ambiguity for
> bison/yacc. I'm a little worried about the kvalue, however. I've set
> it to "LOCK ON". I'd like to figure out a way to delete that token, and
> still not have any shift/reduce or reduce/reduce errors.
>
> Here's the relevant bit from my file.tpl:
>
> lock_mode_clause:
> LOCK opt_mode opt_is manual_or_auto_kw opt_lock_on_clause {
> RSN($1, "Lock Mode not yet supported");
> }
> ;
>
> manual_or_auto_kw:
> MANUAL
> | AUTOMATIC
> ;
>
> opt_lock_on_clause:
> /* nothing */
> | with_lock_on
> ;
>
> with_lock_on:
> opt_with lock_on
> ;
>
> lock_on:
> LOCK_ON record_or_records
> ;
>
> record_or_records:
> RECORD
> | RECORDS
> ;
>
> If I change the "LOCK_ON" to "LOCK ON", I get a reduce/reduce error. I
> would rather not have any errors, but I'm still a little dubious about a
> "LOCK_ON" token.
>
> Thoughts?
> --
> Matthew Vanecek
> perl -e 'print
> $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
> ********************************************************************************
> For 93 million miles, there is nothing between the sun and my shadow
> except me.
> I'm always getting in the way of something...
>
> -----------------------------------------------------------------
> Part 1.2Type: application/pgp-signature |
|
From: Matthew V. <lin...@ho...> - 2001-06-11 01:36:18
|
Tim,
I was working on my file i/o grammar this weekend, and ran into some
issues with the LOCK MODE clause. I've kinda got it figured out, but
I'm not certain that it's the correct way:
I've got a clause:
LOCK [MODE IS] {MANUAL | AUTOMATIC} [[WITH] LOCK ON {RECORD | RECORDS}]
The two LOCKs were causing reduce/reduce errors. I finally ended up
sticking a "LOCK_ON" token in cobctok.def to alleviate the ambiguity for
bison/yacc. I'm a little worried about the kvalue, however. I've set
it to "LOCK ON". I'd like to figure out a way to delete that token, and
still not have any shift/reduce or reduce/reduce errors.=20
Here's the relevant bit from my file.tpl:
lock_mode_clause:
LOCK opt_mode opt_is manual_or_auto_kw opt_lock_on_clause {
RSN($1, "Lock Mode not yet supported");
}
;
manual_or_auto_kw:
MANUAL
| AUTOMATIC
;
opt_lock_on_clause:
/* nothing */
| with_lock_on
;
with_lock_on:
opt_with lock_on
;
lock_on:
LOCK_ON record_or_records
;
record_or_records:
RECORD
| RECORDS
;
If I change the "LOCK_ON" to "LOCK ON", I get a reduce/reduce error. I
would rather not have any errors, but I'm still a little dubious about a
"LOCK_ON" token.
Thoughts?
--
Matthew Vanecek
perl -e 'print
$i=3Dpack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
***************************************************************************=
*****
For 93 million miles, there is nothing between the sun and my shadow
except me.
I'm always getting in the way of something...
|
|
From: Keisuke N. <kx...@po...> - 2001-06-06 19:04:06
|
At Wed, 06 Jun 2001 21:25:56 +1000, Tim Josling wrote: > > With accessor macros, you have to look at the macro to see what > is the underlying field. > > For example in gcc, TREE_USED(x) is common.used_flag. This is > particularly a problem if the same field is used for multiple > things, as it is in gcc (see tree.h). The debugger does not know > about accessor macros AFAIK so in the debugger you have to know > the real field names. static_flag has six different accessor > macros. (snip) > The other thing is that having one giant union means that when > you do a p *x in gdb, the output goes for pages. On the other > hand just having cast into a single struct * makes it more > manageable. That's right, but regarding a debugger, what about writing a debug printer for cobol trees, as GCC has debug_rtx and debug_tree? Keisuke |
|
From: Tim J. <te...@me...> - 2001-06-06 11:33:24
|
Keisuke, With accessor macros, you have to look at the macro to see what is the underlying field. For example in gcc, TREE_USED(x) is common.used_flag. This is particularly a problem if the same field is used for multiple things, as it is in gcc (see tree.h). The debugger does not know about accessor macros AFAIK so in the debugger you have to know the real field names. static_flag has six different accessor macros. Actually I am not really that against accessor macros, I used them in treelang (sample front end) but mainly because I wanted to make it as consistent with gcc as possible. The other thing is that having one giant union means that when you do a p *x in gdb, the output goes for pages. On the other hand just having cast into a single struct * makes it more manageable. I am not against accessor macros if you want to use them in code you write. It would not be a problem to define a %union I don't think. Maybe the existing code would have to have casts added though. I have a clean compile policy. Tim Josling Keisuke Nishida wrote: > ... > > > I don't like accessor macros really because you have to keep > > looking up what actual fields they are accessing. > > Could you explain what you mean here? > > Thanks, > Keisuke Nishida |
|
From: Keisuke N. <kx...@po...> - 2001-06-05 20:39:38
|
At Wed, 06 Jun 2001 06:11:58 +1000, Tim Josling wrote: > > The approach I took is to define seperate structures and do > casts. At first, I used to cast on every access, which became > tedious very quickly (you still see a fair bit of this code lying > around). So now I cast into a variable which is of the right type > and use that variable. This would not cause any runtime slowdown > as the cast is opimized away. This also gives me a good > opportunity to put in an assert or a type check to improve the > integrity of the program. This is the closest to type safeness I > have been able to get. Okay, I think I understand you, though I now prefer accessor macros because of their simplicity, forgetting about type safeness. > I don't like accessor macros really because you have to keep > looking up what actual fields they are accessing. Could you explain what you mean here? Thanks, Keisuke Nishida |
|
From: Tim J. <te...@me...> - 2001-06-05 20:19:29
|
Keisuke,
I have experimented with several different options here and none
of them seem ideal to me.
By having a union, it means that you need to say
ptr->which_one.member
every time you access something. Alternatively you can do what
gcc does, which is have a union but dfine accessor macros eg
TREE_USER(ptr)=1;
I don't like accessor macros really because you have to keep
looking up what actual fields they are accessing.
As far as I can tell, a union is not type safe. If you use the
wrong member it will still not work.
The approach I took is to define seperate structures and do
casts. At first, I used to cast on every access, which became
tedious very quickly (you still see a fair bit of this code lying
around). So now I cast into a variable which is of the right type
and use that variable. This would not cause any runtime slowdown
as the cast is opimized away. This also gives me a good
opportunity to put in an assert or a type check to improve the
integrity of the program. This is the closest to type safeness I
have been able to get.
eg
void myfun (void* ptr1)
{
struct xxx1 *ptr2;
ptr2=(struct xxx1 *) ptr1;
if (ptr2->type != what_i_expect)
abort();
IMHO this gives the best combination of type checking and least
typing, but I woudl like a better solution.
By the way I will be starting work on IF again this weekend which
is a three day weekend here.
Tim Josling
Keisuke Nishida wrote:
>
> Tim,
>
> It seems that you don't use %union in your parser and use lots
> of type castings instead. Is there a good reason to do so?
> I don't think too much use of type casting is a good thing
> because it disables the C compiler from doing type checking.
>
> Keisuke
|
|
From: Tim J. <te...@me...> - 2001-06-03 06:35:56
|
OK I have checked that in now, Tim Josling "Steven O. Ellis" wrote: > > The overflow check for POINTER of zero was > wrapped in preprocessor code for DEBUG only. > I have removed this preprocessor code because > this is a standard overflow check. Per the > standard, it is not a bug if POINTER is set > to zero, it is simply an OVERFLOW condition. > > Attached is the revised file. Tim, please > incorporate it into the CVS tree when you > have time. > > ----------------------------------------------------------------- > Name: cobr_string.c > cobr_string.c Type: Plain Text (text/plain) > Encoding: 7bit |
|
From: Tim J. <te...@me...> - 2001-06-02 21:19:19
|
OK I will incorporate it today, assuming it passes the tests, Tim Josling |
4 messages has been excluded from this view by a project administrator.
