Re: Good practical language and OS agnostic text?

compilers@is-not-my.name wrote:


(snip, I wrote)
>> One Wirth language that you might find interesting is PL/360.


>> PL/360 looks like a high-level language but works like assembly
>> language. As an example (which I am remembering from 40 years ago)


> I have the doc and compiler code, everything was released into the
> public domain. It's so close to assembler I didn't consider it might
> be a good way to learn to write a compiler but maybe it is. A 10
> second look shows it's pretty heavily abstracted. I will have to spend
> more time on it but it may be more a tribute to the traditional Wirth
> terseness than something to learn from, at least without the professor
> around to ask questions of.


Well, there are a few different things you need to know to write a
compiler. One is how to write parsers. Assemblers usually don't need
much parsing, but for something like PL/360 you need most of the same
parser you would for a high-level language.


The code generator will be much simpler, though.


Parsing theory is fairly well understood, though that doesn't
mean it is easy to learn. The theory for code generators is still
somewhat of an art, especially for the newer processors like Itanium.
(I have an actual Itanium RX2600 running VMS, but likely won't
ever try to write a compiler for it.)


>> But I don't understand your refusal to use the tools that are
>> available.


> As I said they're not available on my target platform.


There is an IBM supplied C compiler for z/OS. I don't know how
much it costs, though.


Personally, I wouldn't mind having a z/OS machine at home but
can't afford one. (I might afford the hardware, but not the OS.)


I even don't mind writing JCL. By 9th grade, I was reading IBM
manuals like books, could write my own JCL, and it never bothered
me to do it.


I presume compiling FLEX and BISON on the IBM C compiler
would be pretty easy. But even so, you could do everything
as a cross compiler, running on another machine generating
z/OS assembler code, then copying it and assembling on z/OS.


>> FLEX and BISON are freely available, you can't complain that
>> they cost too much.


> True but irrelevant!


>> You can run them on a freely available OS (Linux, FreeBSD,
>> Solaris, etc.) on machines that you can find for very low
>> prices, or often enough given away.


I can't afford z/OS, but I can other systems. I don't mind working
on those other systems, even generating code for machines
I don't have.


> Ok but those aren't my targets. I'm not interested in using
> those for this project, as I said. And I would really like
> to understand what I am doing and the way I have always done
> that is to write my own code. Why is that upsetting (hard to
> understand, etc.) to you? I haven't mentioned the cost of
> anything, I'm not sure where you are coming from here.


Sometimes what you write seems like whining. Yes, I would like
to have a z/OS machine, running the IBM Enterprise PL/I compiler,
VS Fortran, Fortran H Extended, and a few other compilers and
assemblers. I don't have those, so I work with what I have.


>> The nice thing about the tools is that you can get something running
>> fairly fast, and without needing to get too deep into the math. You
>> can go as deep or shallow into the innards of FLEX and BISON as you
>> want. One project that should be about right for one person, and
>> without a lot of math, is rewriting FLEX and BISON to generate code in
>> another language, such as PL/I.


> It would be nice to "get something running fairly fast" but if I
> do that depending on other pieces I don't understand it doesn't
> really help me. I want to learn as much as I can doing this.


It is difficult to learn everything at the same time.


I suppose you could write everything in assembler, or even
punch the binary codes directly into punched cards. Using
high-level languages makes it a little easier.


People use tools because it gets them where they want to
be faster.


Reminds me of the instructions for submitting bug reports to GNU.
They expect to use the debugger to find problems, and so don't
need the low level details that one might otherwise supply.


I pretty much never debugged from hex dumps, but usually knew my
programs well enough that if I knew close to where the problem was,
I could figure it out. Sometimes I might consider using a
debugger as cheating.


You could learn all about how to write parsers, convince yourself
that BISON generated parsers according to theory that you understood,
and then allow yourself to use it.


As I wrote, rewriting BISON in PL/I, and to generate parsers
in PL/I might be a nice project to keep someone busy, and also
learn about how it works at the same time. (Especially if you
don't like C.)


You could also write your own parser generator, in your favorite
language, generating code in your favorite language, and using
your favorite parsing method. That would be more work, though,
but you would learn more that way.


>> [PL/360 was a great little language, but the source code to the
>> compiler was apparently lost. -John]


> I believe Jay Maynard is hosting several PL/360 packages.
> AFAIK they are complete.


> [If so, they'd be a good place to start. It's basically an assembler
> with Algol syntax, so it has a real parser. -John]


I thought PL/360 source was available, and ALGOL W was lost, but I
could have forgotten. There is now a scanned source listing of some
version, likely not the last, of ALGOL W. (Written in PL/360.)


Not so long after I started learning Fortran, about the time I
was learning PL/I, I had an ALGOL W manual. I remember being
impressed that it allowed 256 character identifiers, compared to
six for Fortran. It might be that I never tried running it, though.


-- glen

Return to the comp.compilers page.
Search the comp.compilers archives again.