[Fwd: Cobol compiler sources] 
Author Message
 [Fwd: Cobol compiler sources]

'Twas Thu, 17 Jun 1999 13:57:29 +0100, when Ken Foskey

Quote:
> I have released a (historic) Cobol compiler that may be useful for
> someone
> trying to implement such language to another OS (Linux?!). It's written
> mostly
> in C, with a few x86 assembler routines.

A compiler is a batch application.  Unless the C compiler was woefully
defficient, I can't imagine why anyone would need to write parts in
assembler.
--
R B |\  Randall Bart

n r |\  1-614-308-9307      Please reply without spam       I Love You
d t ||\ Have you solved http://www.*-*-*.com/
a    |/ MS^7=6/28/107             Let's sing about the Year 2000 Bugs:
l    |\             http://www.*-*-*.com/
l    |/ Has anyone in Washington DC read the US Constitution?


Thu, 06 Dec 2001 03:00:00 GMT  
 [Fwd: Cobol compiler sources]


.

Quote:

> A compiler is a batch application.  Unless the C compiler was woefully
> defficient, I can't imagine why anyone would need to write parts in
> assembler.

Could it be that, in spite of claims to the contrary, that  C  can't do
everything? Nahh, probably not.


Thu, 06 Dec 2001 03:00:00 GMT  
 [Fwd: Cobol compiler sources]

Quote:

>'Twas Thu, 17 Jun 1999 13:57:29 +0100, when Ken Foskey

>>[...] It's written
>> mostly
>> in C, with a few x86 assembler routines.

>A compiler is a batch application.  Unless the C compiler was woefully
>defficient, I can't imagine why anyone would need to write parts in
>assembler.

Self-satisfaction! Some people have a need to write assembler
because they can; not because it is required.
------------------
Rick Smith


Thu, 06 Dec 2001 03:00:00 GMT  
 [Fwd: Cobol compiler sources]

Quote:



>> A compiler is a batch application.  Unless the C compiler was woefully
>> defficient, I can't imagine why anyone would need to write parts in
>> assembler.

>Could it be that, in spite of claims to the contrary, that  C  can't do
>everything? Nahh, probably not.

I would be interested in seeing the source of those claims!

A knowledgeable person would allow that booting a computer
and task switching in an OS kernel would require assembler,
regardless of any implementation language, and that for C, in
particular, language extensions, which provide access to
hardware resources, would require some assembler.

The rest of the OS, interrupt service routines, device drivers, and
other access to hardware or the OS can use this extended version
of the C language. Off-hand, I can think of nothing else that could
not be written in standard C.

Therefore, IMO, most of a standard COBOL compiler and most
of the run-time environment could be written in standard C. The
balance using the platform extensions to C. No assembler is
required to implement a COBOL compiler when using the C
Programming Language.

The bottom line is that assembler is not required except as
noted above and for improving speed. I have also noticed
that some people (I have seen their programs) have a knack
for using assembler in all the wrong places.
------------------
Rick Smith



Thu, 06 Dec 2001 03:00:00 GMT  
 [Fwd: Cobol compiler sources]
The Micro Focus compiler is (and always was) written in COBOL - and is
hardly a "little" compiler.

--
Bill Klein
    wmklein <at> ix dot netcom dot com

Quote:
> His assembler is there to to interface to the OS (if you can call
> DOS an OS), fiddle with the stack, etc.

> Given a reasonable C compiler, there is little need for assembler
> apart from the odd inner loop and for OS and hardware
> interfacing.

> You would not consider writing a compiler in COBOL though -
> actually I did write a small compiler in COBOL once because the
> customers insisted - it needed some assembler subroutines -  but
> I would not recommend it.

> Tim Josling




> > .

> > > A compiler is a batch application.  Unless the C compiler was woefully
> > > defficient, I can't imagine why anyone would need to write parts in
> > > assembler.

> > Could it be that, in spite of claims to the contrary, that  C  can't do
> > everything? Nahh, probably not.



Fri, 07 Dec 2001 03:00:00 GMT  
 [Fwd: Cobol compiler sources]
His assembler is there to to interface to the OS (if you can call
DOS an OS), fiddle with the stack, etc.

Given a reasonable C compiler, there is little need for assembler
apart from the odd inner loop and for OS and hardware
interfacing.

You would not consider writing a compiler in COBOL though -
actually I did write a small compiler in COBOL once because the
customers insisted - it needed some assembler subroutines -  but
I would not recommend it.

Tim Josling

Quote:



> .

> > A compiler is a batch application.  Unless the C compiler was woefully
> > defficient, I can't imagine why anyone would need to write parts in
> > assembler.

> Could it be that, in spite of claims to the contrary, that  C  can't do
> everything? Nahh, probably not.



Sat, 08 Dec 2001 03:00:00 GMT  
 [Fwd: Cobol compiler sources]

Quote:

> His assembler is there to to interface to the OS (if you can call
> DOS an OS), fiddle with the stack, etc.

> Given a reasonable C compiler, there is little need for assembler
> apart from the odd inner loop and for OS and hardware
> interfacing.

> You would not consider writing a compiler in COBOL though -
> actually I did write a small compiler in COBOL once because the
> customers insisted - it needed some assembler subroutines -  but
> I would not recommend it.

> Tim Josling




> > .

> > > A compiler is a batch application.  Unless the C compiler was woefully
> > > defficient, I can't imagine why anyone would need to write parts in
> > > assembler.

> > Could it be that, in spite of claims to the contrary, that  C  can't do
> > everything? Nahh, probably not.

Tim,

Simplistic maybe, but what keeps going through my mind, is why the hell
we have to keep going through C or assembler to get to the machine.
Back to basics - the machines work in ones and noughts, then along came
the shorthand ASSEMBLER. Next fortran which was A-OK but didn't do it
for commerce so we have COBOL. Then Simula/Smalltalk for simulation and
manipulating objects. Next bat, C, Pascal etc, then the latest 'darling'
Java.

Consider all the possible COBOL programmers lost to these 'new'
languages,  (a) because they didn't like the discipline of COBOL, and
(b) more importantly, COBOL was lacking features that they wanted/needed
to use.

As Bill Klein has indicated, the MF Compiler is written in COBOL.
Similarly, 90%+ of the NetExpress IDE is written with COBOL OO/GUI,
making extensive use of collections/dictionaries. (No - it's not a plug
for MF - just meant to be informative).

If COBOL is lacking some neat features which are available in C or some
other language shouldn't we be screaming blue {*filter*} at our Standards
people for their inclusion. I've indicated elsewhere that the OO
Standards have acknowledged the neat features of Smalltalk - which are
the basis of COBOL's OO collections/dictionaries.

COBOL is machine-oriented but it is a subset of the ENGLISH language.
ENGLISH is a bastard language anyway, Norse, (Angles, Saxons, and
Danes), some 50% of the words are filched from the French, just
pronounced differently.  Queen Vicky's scarlet-clad lads went about
'grabbing' the Empire, (and sending the first 'occupants' to your part
of the world from Portsmouth). When the troops returned home they
unashamedly introduced new words/concepts. Got a problem expressing it
in English, then hi-jack from Greek or Latin. If it's philosophical,
then pinch it from German. And just think about that bunch of
ingratiates, just south of me; they got uppity, threw a tea-party - and
look what they've done to the language!

Take a language group - why do I write in COBOL(English) and use
C(Dutch) to communicate with Machine Code(German). If C(Dutch) has
useful words, such as 'yacht' then put them in COBOL(English).

We desperately need our own COBOL virtual machine - recognising all
platforms, always returning the same results, (which would negate people
getting their knickers-in-a-twist worrying about how pic 9(06) comp-3
will be stored on a mainframe as opposed to a PC). Sorry to plug it, but
OO is probably the best route to achieve compatibility.

If we had our own COBOL-specific virtual machine, (platform-independent)
and unashamedly steal good concepts from other languages - we could
knock the socks off the latter for efficiency/portability - and yes,
longevity. (Perhaps we could get some of the geeks who use the 'cryptic'
languages to return to the COBOL fold.)

Dare I say it: what I'm really after is something I call OPEN COBOL, (a
la Linux,  where people can jump in and add tools to the basic system.
There's a university team (U of Maryland ?) writing a COBOL compiler for
Linux - but it's the usual cop-out - they are using C as the
intermediary language).

Jimmy, Calgary AB



Sat, 08 Dec 2001 03:00:00 GMT  
 [Fwd: Cobol compiler sources]
good stuff, Jimmy.
I agree completely with you.



Quote:

> > His assembler is there to to interface to the OS (if you can call
> > DOS an OS), fiddle with the stack, etc.

> > Given a reasonable C compiler, there is little need for assembler
> > apart from the odd inner loop and for OS and hardware
> > interfacing.

> > You would not consider writing a compiler in COBOL though -
> > actually I did write a small compiler in COBOL once because the
> > customers insisted - it needed some assembler subroutines -  but
> > I would not recommend it.

> > Tim Josling




> > > .

> > > > A compiler is a batch application.  Unless the C compiler was
woefully
> > > > defficient, I can't imagine why anyone would need to write parts in
> > > > assembler.

> > > Could it be that, in spite of claims to the contrary, that  C  can't
do
> > > everything? Nahh, probably not.

> Tim,

> Simplistic maybe, but what keeps going through my mind, is why the hell
> we have to keep going through C or assembler to get to the machine.
> Back to basics - the machines work in ones and noughts, then along came
> the shorthand ASSEMBLER. Next FORTRAN which was A-OK but didn't do it
> for commerce so we have COBOL. Then Simula/Smalltalk for simulation and
> manipulating objects. Next bat, C, Pascal etc, then the latest 'darling'
> Java.

> Consider all the possible COBOL programmers lost to these 'new'
> languages,  (a) because they didn't like the discipline of COBOL, and
> (b) more importantly, COBOL was lacking features that they wanted/needed
> to use.

> As Bill Klein has indicated, the MF Compiler is written in COBOL.
> Similarly, 90%+ of the NetExpress IDE is written with COBOL OO/GUI,
> making extensive use of collections/dictionaries. (No - it's not a plug
> for MF - just meant to be informative).

> If COBOL is lacking some neat features which are available in C or some
> other language shouldn't we be screaming blue {*filter*} at our Standards
> people for their inclusion. I've indicated elsewhere that the OO
> Standards have acknowledged the neat features of Smalltalk - which are
> the basis of COBOL's OO collections/dictionaries.

> COBOL is machine-oriented but it is a subset of the ENGLISH language.
> ENGLISH is a bastard language anyway, Norse, (Angles, Saxons, and
> Danes), some 50% of the words are filched from the French, just
> pronounced differently.  Queen Vicky's scarlet-clad lads went about
> 'grabbing' the Empire, (and sending the first 'occupants' to your part
> of the world from Portsmouth). When the troops returned home they
> unashamedly introduced new words/concepts. Got a problem expressing it
> in English, then hi-jack from Greek or Latin. If it's philosophical,
> then pinch it from German. And just think about that bunch of
> ingratiates, just south of me; they got uppity, threw a tea-party - and
> look what they've done to the language!

> Take a language group - why do I write in COBOL(English) and use
> C(Dutch) to communicate with Machine Code(German). If C(Dutch) has
> useful words, such as 'yacht' then put them in COBOL(English).

> We desperately need our own COBOL virtual machine - recognising all
> platforms, always returning the same results, (which would negate people
> getting their knickers-in-a-twist worrying about how pic 9(06) comp-3
> will be stored on a mainframe as opposed to a PC). Sorry to plug it, but
> OO is probably the best route to achieve compatibility.

> If we had our own COBOL-specific virtual machine, (platform-independent)
> and unashamedly steal good concepts from other languages - we could
> knock the socks off the latter for efficiency/portability - and yes,
> longevity. (Perhaps we could get some of the geeks who use the 'cryptic'
> languages to return to the COBOL fold.)

> Dare I say it: what I'm really after is something I call OPEN COBOL, (a
> la Linux,  where people can jump in and add tools to the basic system.
> There's a university team (U of Maryland ?) writing a COBOL compiler for
> Linux - but it's the usual cop-out - they are using C as the
> intermediary language).

> Jimmy, Calgary AB



Sat, 08 Dec 2001 03:00:00 GMT  
 [Fwd: Cobol compiler sources]
If you look at the new COBOL standard, most of the additions are
borrowings from C or C++ and perhaps Smalltalk. That's healthy I
think and illustrates my point perfectly. By the same token,
C/C++/Java implementations iften have some decimal extensions.

But what annoys me is the way they have done everything
differently, for reasons that escape me. Why not // for inline
comments rather than <* ? Why is the conditional compilation
gratuitously different? Why not at least try and contain the
reserved word problem by starting all new reserved words with $
or % or something?

The main problems with COBOL 85 for writing a compiler were

- dynamic memory allocation and pointers (so you end up with lots
of fixed limits from arbitrary array sizes) - everyone had a
different incompatible pointers extension.
- defined constants (REPLACE doesn't cut it).
- lack of bit fields

These are more or less fixed in CD1.5. The pointers are done in a
very clumsy way though. For example, in C you can resolve an
arbitrary number of levels of pointers in one expression, but on
my reading not in the new cobol - so you have to create all those
temporary variables, just like everyone does now because you
cannot trust the compute statement to deliver predictable
results.

You still have the problem of the low rate of function points per
statement in COBOL. It just takes more typing than C. At college
my lecturer rewrote a report writing program from COBOL into
Fortran - it was half the size. Nothing has been done to address
this problem.

This is worse for compiler writers because there are no tools I
have been able to find similar to C's lex and yacc for COBOL, so
you need to RYO tools or hand code the compiler.

And they have added another bagfull of reserved words, breaking
existing programs. By the way, does anyone know a simple way to
avoid reserved words? I used to use a number on the end of every
variable eg temp1, but they then broke that (Cobol 85 I think).

A lot of the COBOL compilers written seem to have been written in
assembler, but I wouldn't recommend that either.

Is there a reference for the claim that MF Cobol is written in
COBOL - is it all in COBOL - I don't see how that would be
possible? Has anyone compared the speed of MF COBOL to a C
compiler (from what I am told but have not been able to confirm
it is more than 10X slower than a typical C compiler)?

I only became aware of the new standard recently and it looks
like it is too late to do much about it unfortunately. Apart from
the substance of the standard, there are far too many ambiguities
and implementation dependent issues. They actually admit they
have given up trying to specify the interaction between debug and
COPY/REPLACE for example.

I think COBOL is best for certain kinds of applications,
especially on MVS. Maybe trying to turn it into C is a mistake
(IBM tried that already with PL/I).

Tim Josling

Quote:

...
> Tim,

> Simplistic maybe, but what keeps going through my mind, is why the hell
> we have to keep going through C or assembler to get to the machine.
> Back to basics - the machines work in ones and noughts, then along came
> the shorthand ASSEMBLER. Next FORTRAN which was A-OK but didn't do it
> for commerce so we have COBOL. Then Simula/Smalltalk for simulation and
> manipulating objects. Next bat, C, Pascal etc, then the latest 'darling'
> Java.

> Consider all the possible COBOL programmers lost to these 'new'
> languages,  (a) because they didn't like the discipline of COBOL, and
> (b) more importantly, COBOL was lacking features that they wanted/needed
> to use.

> As Bill Klein has indicated, the MF Compiler is written in COBOL.
> Similarly, 90%+ of the NetExpress IDE is written with COBOL OO/GUI,
> making extensive use of collections/dictionaries. (No - it's not a plug
> for MF - just meant to be informative).

> If COBOL is lacking some neat features which are available in C or some
> other language shouldn't we be screaming blue {*filter*} at our Standards
> people for their inclusion. I've indicated elsewhere that the OO
> Standards have acknowledged the neat features of Smalltalk - which are
> the basis of COBOL's OO collections/dictionaries.

...


Sun, 09 Dec 2001 03:00:00 GMT  
 [Fwd: Cobol compiler sources]

Quote:

> If you look at the new COBOL standard, most of the additions are
> borrowings from C or C++ and perhaps Smalltalk. That's healthy I
> think and illustrates my point perfectly........etc....

Tim,

Now that I've got a direct cable connection, with a fixed fee per month,
and can tap away at the keyboard for 28 hours a day - I'm finding this
internet stuff can get {*filter*}ive. I gotta sit down and actually write
some COBOL code to earn my bread.

I'll digest your message and will reply in due course - promise.

Jimmy, Calgary AB



Sun, 09 Dec 2001 03:00:00 GMT  
 [Fwd: Cobol compiler sources]


Quote:
>But what annoys me is the way they have done everything
>differently, for reasons that escape me. Why not // for inline
>comments rather than <* ? Why is the conditional compilation
>gratuitously different? Why not at least try and contain the
>reserved word problem by starting all new reserved words with $
>or % or something?

// is traditionally IBM JCL.

Second point - how many words do you know that start with $ or %?  

That's the point, and the MAIN strength of COBOL.  I can show COBOL
code to my C programming buddy, who has never seen COBOL, and he can
tell what it is doing.  When the accounting department comes to me and
says a calculation is wrong, and it's not, I can SHOW them and they
can see it.  You would not believe the reassurance that buys.  When
you start throwing =+ and X << Y around, only the programmers know
whats going on.  Not necessarily a good thing.



Sun, 09 Dec 2001 03:00:00 GMT  
 [Fwd: Cobol compiler sources]

Quote:
> You would not consider writing a compiler in COBOL though -

I thought the MicroFocus (sorry Merant) compilers *are* written in COBOL?

+--------------+------------------------------------+

|              | http://www_dot_cix.co.uk/~watkins/ |
+--------------+------------------------------------+



Sun, 09 Dec 2001 03:00:00 GMT  
 [Fwd: Cobol compiler sources]
'Twas Wed, 23 Jun 1999 11:29:45 +1000, when Tim Josling

Quote:
> Why not at least try and contain the
> reserved word problem by starting all new reserved words with $
> or % or something?
> And they have added another bagfull of reserved words, breaking
> existing programs. By the way, does anyone know a simple way to
> avoid reserved words? I used to use a number on the end of every
> variable eg temp1, but they then broke that (Cobol 85 I think).

I think the new reserved word problem is a red herring.  How often to you
go to a new standard with new reserved words?  It's ten years or more.  On
that rare occaision you can can run a filter against all your old sources
to change all the new reserved words to something else.

But because so many people raised this silly issue, COBOL-85 did include
an almost promise not to have any reserved words starting with X, Y, or Z
(except the existing ZERO/ZEROS/ZEROES) or with just one or two characters
before the first hyphen (except the existing I-O and I-O-CONTROL).

Unfortunately they've broken this rule by making the EC-I-O-xx exception
names reserved words on compiler directives, but at least there aren't old
compiler directives to break.

The intent is to keep Cobol somewhat English-like, so putting a special
character in all the new reserved words is out of the question.  But as I
said, is running a filter against all your sources every ten years such a
problem?
--
R B |\  Randall Bart

n r |\  1-614-308-9307      Please reply without spam       I Love You
d t ||\ Have you solved http://users.aol.com/PanicYr00/Sequence.html ?
a    |/ MS^7=6/28/107             Let's sing about the Year 2000 Bugs:
l    |\             http://users.aol.com/PanicYr00/SongMiscellany.html
l    |/ Has anyone in Washington DC read the US Constitution?



Mon, 10 Dec 2001 03:00:00 GMT  
 [Fwd: Cobol compiler sources]
Besides what Randall says in the "attached," the draft also introduces a new
concept called "reserved in context" or "context-sensitive reserved words".
These are new words that CAN still be used as "user-defined" words
(data-names, paragraph-names, etc) but have a "special meaning" in certain
specific constructs (where a user-defined word can never occur).  The whole
purpose of this WAS to reduce the number of new reserved words.

--
Bill Klein
    wmklein <at> ix dot netcom dot com

Quote:
> 'Twas Wed, 23 Jun 1999 11:29:45 +1000, when Tim Josling

> > Why not at least try and contain the
> > reserved word problem by starting all new reserved words with $
> > or % or something?

> > And they have added another bagfull of reserved words, breaking
> > existing programs. By the way, does anyone know a simple way to
> > avoid reserved words? I used to use a number on the end of every
> > variable eg temp1, but they then broke that (Cobol 85 I think).

> I think the new reserved word problem is a red herring.  How often to you
> go to a new standard with new reserved words?  It's ten years or more.  On
> that rare occaision you can can run a filter against all your old sources
> to change all the new reserved words to something else.

> But because so many people raised this silly issue, COBOL-85 did include
> an almost promise not to have any reserved words starting with X, Y, or Z
> (except the existing ZERO/ZEROS/ZEROES) or with just one or two characters
> before the first hyphen (except the existing I-O and I-O-CONTROL).

> Unfortunately they've broken this rule by making the EC-I-O-xx exception
> names reserved words on compiler directives, but at least there aren't old
> compiler directives to break.

> The intent is to keep Cobol somewhat English-like, so putting a special
> character in all the new reserved words is out of the question.  But as I
> said, is running a filter against all your sources every ten years such a
> problem?
> --
> R B |\  Randall Bart

> n r |\  1-614-308-9307      Please reply without spam       I Love You
> d t ||\ Have you solved http://users.aol.com/PanicYr00/Sequence.html ?
> a    |/ MS^7=6/28/107             Let's sing about the Year 2000 Bugs:
> l    |\             http://users.aol.com/PanicYr00/SongMiscellany.html
> l    |/ Has anyone in Washington DC read the US Constitution?



Mon, 10 Dec 2001 03:00:00 GMT  
 [Fwd: Cobol compiler sources]
(forwarded from Rick Smith)
I can't send this to the newsgroup because the news server is
completely out. Feel free to post any of this to the newgroup.

<< Is there a reference for the claim that MF Cobol is written in
COBOL - is it all in COBOL - I don't see how that would be
possible? >>

There was a book, distributed with some MF systems in the
early 80's, that gave the, then brief, history of Micro Focus.
This
book mentioned how they used SNOBOL to bootstrap their first
COBOL compiler. IIRC, this book also made the statement that
MF COBOL was, at that time, written in COBOL. I would cite
a full reference and veridy the statement but the book is buried
in a box in a closet.

That later versions of MF COBOL were written in COBOL was
obvious from looking at the content of the .LIB (early) and .LBR
(later) files that were distributed with the system. Code in
these
files used a .GNT or .Gxx suffix which is characteristic of MF
COBOL generated code. The .GNT designates a dynamically
linked COBOL sub program. The .Gxx, where xx is a number,
designates dynamic overlays in MF COBOL.

Certainly some assembler was used for interfacing to the
operating system and to hardware resources; but these were
likely accomplished by using CALL X"xx" where xx was a hex
number from 80 through FF. These CALLs are part of the
runtime system that is available to all users.

The editor, compiler (to intermediate code), and native code
generator (to machine code) were written in COBOL at
least through the Workbench products.

Beginning in the 90's, Micro Focus began using the C
language in some utilities that were shipped as part of the
system. This was obvious from CALLs that required null-
terminated strings.

In NetExpress, they may have replaced the editor and certainly
the user interface with C++ using MFC, since this is a
Windows-only product. This was implied in a post, to the
newsgroup, from a Micro Focus "insider."
----------------
Rick Smith



Tue, 11 Dec 2001 03:00:00 GMT  
 
 [ 33 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. [Fwd: Cobol compiler sources]

2. Mikro Focus Cobol Compiler 3.0/ Personal Cobol Compiler 2.0

3. COBOL Compiler Source

4. COBOL Open Source (Free) Compiler

5. COBOL compiler source code

6. Source Code for a Cobol 85 Compiler Front End

7. Fwd: [LogoForum] Compiling logo sources

8. Anyone have source to units....... (fwd)

9. Fwd: Dylan Sample Source

10. Fwd: Open Source issue of Release 1.0

11. [Fwd:2nd Workshop on Open Source Software Engineering]

12. Cobol Source for Cobol Syntax formatter wanted

 

 
Powered by phpBB® Forum Software