censored by comp.compilers [was please suggest an OS and language agnostic compiler text]

[comp...@is-not-my.name]

glen herrmannsfeldt <g...@nospam.ugcs.caltech.edu> wrote:

>> 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.

I gathered that from John's comments as well. Thanks to you both.

>>>> 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.

I have access to pretty much everything at work. I didn't think Bison and
Flex would run on z/OS (they probably would on z/Linux but I'm not using
that) and I've said a few times I'm not interested in C. There, I've said it
again. No offense.

> 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.)

This is what I work with so it's what I know, like and use. Please remember
the subject line and don't keep trying to sell me specific stuff or at least
if you do keep trying don't blame me for not buying. I was looking for
books, not software anyway. That's what the post was all about but for some
reason the replies mostly intermingled UNIX and C evangelism with a few
condescending insults from the usual snobs and a couple of pretty good
on-topic answers. Embarassing signal to noise ratio on this but I guess that
was expected given the audience. Try to swing a dead cat without hitting a
UNIX or C groupie on the internet...not easy.

> 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.

That is an interesting theory. I can think of one compiler that could do
that but that is not a free compiler either and I don't think it's very
popular although it is reputed to be good. They're thinking of buying it
at work. gcc won't do it because it doesn't have a z/OS target as far
as I know. I am pretty sure it does have a z/Linux target though. If you're
interested you could run a free Linux on Hercules and do all the latest
stuff you can't get me to do. After all it's free, so don't whine about it!

> 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.

That is fine for you but you are answering questions I didn't ask and then
blaming me for reminding you I'm not using the tools or platforms you keep
trying to sell me. I find all of what you write interesting (the first
couple of times anyway) and you can say whatever John lets you, it's his
mailing list. [and he has proven that by censoring the thread (as usual) so
this is going to comp.lang.misc] But do realize when you keep talking about
using open source OS and tools I've said I'm not using, that doesn't help
with what I asked which was for suggestions on books, not so-called "free
software" operating systems or tools.

Thanks to you and the others I have already decided to go with the older
books you mentioned. Aside from flogging a dead horse my question has been
answered already but this post is going to the net for posterity.

>> 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.

Sometimes what you write seems like nagging. I've said repeatedly what my
target is and what I prefer to use. You keep trying to make me justify why I
don't use the tools and language you suggest for implementing this. I work
with what I have and am familiar with. I heard your suggestions and I said
thanks but no thanks several times. Is that whining because I didn't agree
to do what you said no matter how many times you tried to make me? Maybe if
you would stop nagging me you would not perceive any whining. Then again
maybe I didn't understand what you wrote in the above paragraph because it
seems like you're accusing me of whining for sharing a similar view to you
about using what I have. That can't be right and I really don't care except
I think your accusation is very bizarre and has no basis in reality.

>>[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]

Thanks, John. Correction, I wrote "Jay Maynard" but I should have written
"Jay Moseley". Jay Moseley has archives of most of the language products
available for S/360 and S/370. They also run on modern machines. This
correction should have at least been posted on comp.compilers, but no.

> 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.)

There are a few ALGOL packages available on Jay Moseley's site but a quick
check of what I have suggests they may be OCO. I don't see ALGOL W but I do
remember some discussion a few years ago. I think it has been recovered but
I don't have it. I have ALGOL68 and the IEX00 ALGOL. They might be one and
the same, I haven't checked. I do believe the ALGOL W source was recovered.

[Rugxulo]

Hi,
I think you're the same anonymous guy I've seen in various
newsgroups, heh. Unfortunately, I think you block all Google Groups
due to spam, so you seeing this will be delayed. Well, it's not THAT
useful info, esp. since I haven't personally written any compilers
(yet). But they are definitely interesting. Anyways, on with the
show ....

On May 4, 1:08 pm, compil...@is-not-my.name wrote:

> glen herrmannsfeldt <g...@nospam.ugcs.caltech.edu> wrote:
>
> >>>> 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.
>
> I have access to pretty much everything at work. I didn't think Bison and
> Flex would run on z/OS (they probably would on z/Linux but I'm not using
> that) and I've said a few times I'm not interested in C. There, I've said it
> again. No offense.

I get it. C is everywhere, everybody pushes it. It has some nice
features and "can be" relatively portable. The syntax leaves some
things to be desired, but overall it's not that bad. But it's also not
my favorite. Still, it is so universal and popular that you almost
can't ignore it. Almost.

> > 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.)
>
> This is what I work with so it's what I know, like and use. Please remember
> the subject line and don't keep trying to sell me specific stuff or at least
> if you do keep trying don't blame me for not buying. I was looking for
> books, not software anyway. That's what the post was all about but for some
> reason the replies mostly intermingled UNIX and C evangelism with a few
> condescending insults from the usual snobs and a couple of pretty good
> on-topic answers. Embarassing signal to noise ratio on this but I guess that
> was expected given the audience. Try to swing a dead cat without hitting a
> UNIX or C groupie on the internet...not easy.

Yes, I hate to say it, no offense intended to anyone, yes *nix is semi-
popular, but the constant propaganda of "Linux Linux Linux" is 1000x
overblown (and they often hide behind "POSIX") and can be annoying.
Not so much that it's so bad, but it's often not portable enough or is
really complicated and messy. Not great for anyone using another
"lesser" OS. You will not find a lot of Linux users who care about
other OSes. I don't know why. So it's not always easy to share code.

> > 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.
>
> That is an interesting theory. I can think of one compiler that could do
> that but that is not a free compiler either and I don't think it's very
> popular although it is reputed to be good. They're thinking of buying it
> at work. gcc won't do it because it doesn't have a z/OS target as far
> as I know. I am pretty sure it does have a z/Linux target though. If you're
> interested you could run a free Linux on Hercules and do all the latest
> stuff you can't get me to do. After all it's free, so don't whine about it!

Yeah, I don't know what your OS provides. I think you mentioned before
liking Ada (and since you mention Algol-W below, I guess that makes
you Wirth-ian). I sympathize.

> > 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.
>
> That is fine for you but you are answering questions I didn't ask and then
> blaming me for reminding you I'm not using the tools or platforms you keep
> trying to sell me. I find all of what you write interesting (the first
> couple of times anyway) and you can say whatever John lets you, it's his
> mailing list. [and he has proven that by censoring the thread (as usual) so
> this is going to comp.lang.misc] But do realize when you keep talking about
> using open source OS and tools I've said I'm not using, that doesn't help
> with what I asked which was for suggestions on books, not so-called "free
> software" operating systems or tools.

Your best bet will be going the Wirth route, which means Pascal or
similar. FreePascal is pretty good, but I don't know how easy (or not)
it would be to cross-compile to your target. You'd probably have an
easier time using PL/0 (from original 1976 _Algorithms + Data
Structures = Programs_, supposedly not in the 1986 Modula-2 edition)
or Oberon/0 from Wirth's compiler book (only latter is online
in .pdf). But even those rely on "classic" Pascal syntax and Oberon OS
interfaces, respectively, which aren't exactly popular anymore. And
they're only minimal subsets, but you could always tweak them to
whatever dialect (FreePascal?) is available (in theory, probably not
super easy but not impossible). Same for P4 or P5 Pascals (both
available online, heavily documented). BTW, PL/0 inspired both Turbo
Pascal and XPL0.

> > 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.)
>
> There are a few ALGOL packages available on Jay Moseley's site but a quick
> check of what I have suggests they may be OCO. I don't see ALGOL W but I do
> remember some discussion a few years ago. I think it has been recovered but
> I don't have it. I have ALGOL68 and the IEX00 ALGOL. They might be one and
> the same, I haven't checked. I do believe the ALGOL W source was recovered.

So you don't like yacc and lex, I don't blame you. I guess the best
"language agnostic" alternative would be Coco/R, for LL(1) I suppose.
And Pat Terry has a book online about compilers using it. Coco/R has
been itself ported to various languages: Pascal, Ada, Modula-2, Java, C
++, etc. It's quite funny, actually!

http://www.scifac.ru.ac.za/coco/
http://www.scifac.ru.ac.za/compilers/

His compiler book is an older version that uses C++, but it also has
equivalent code for Turbo Pascal and Modula-2 off-line. It's meant to
be an introduction. While I haven't really studied it, it looks pretty
good and fairly exhaustive, more complex than it sounds!

I sympathize with you, lots of people tend to drop "older" languages
in lieu of Java or C# (ugh, why?). Seriously, it's kinda horrific. For
instance, Andrew Appel has some compiler books (and teaches a course),
but nowadays he seems to focus on Java (whereas older editions used C+
+ or C, which I would almost prefer for simplicity, even though they
aren't my languages of choice). He doesn't have a book online, but I'm
just telling you for comparison.

http://www.cs.princeton.edu/~appel/

Oops, I might've been thinking of Ronald Mak instead!

http://www.cs.sjsu.edu/~mak/CS153/index.html

And there are other books (Thomas Pittman re: Modula-2), though not
online, but his website is probably still interesting.

http://www.ittybittycomputers.com/

There's also Welsh's "standard" [old] Pascal compiler implementation
book from the '80s, but it seems hard to find and fairly expensive.
Plus, "classic" Pascal is heavily shunned these days, and I'm not sure
how useful that is (I don't have it, and writing a standard Pascal
compiler in standard Pascal may not be useful to you unless you want
to use GCC-based GPC, heh, which I doubt, though it is a nice
compiler, just hard to bootstrap!). You'd do better, IMO, to focus on
P5 (P4 brought up to full standard Pascal), which is documented and
available online and is public domain.

GWU / NYU Ada (83) exists too in C sources, though I know you despise
that, but it's the only Ada that I could think of that is relatively
useful and semi-portable. But I don't even know if it will compile,
they used an old Intel compiler for DOS. But I'm sure it can't be that
hard to port to OpenWatcom or whatever (famous last words!).

I know you've been interested in Forth, too. At least Forth has almost
no syntax, so it should be easier to port. But if you're interested in
Wirth languages, grammar, LL(1), or something in the vein of Algol,
you'll have to read up on some of Wirth's stuff (or similar). There is
an old old Modula-2 subset out there somewhere written in old old
Forth, though I've never tried it. FPC (Forth-83) for DOS supposed had
a Pascal subset translator or whatever. Even old CAML Light had
something similar. Maybe even UCB Logo did too, I can't remember. So
you can write a compiler in anything, it just depends on how complex
you want to make it!

Good luck! You'll need it. ;-)

[BGB]

just responding here to the parts I have something to comment on.

On 5/4/2012 2:09 PM, Rugxulo wrote:

>> I have access to pretty much everything at work. I didn't think Bison and
>> Flex would run on z/OS (they probably would on z/Linux but I'm not using
>> that) and I've said a few times I'm not interested in C. There, I've said it
>> again. No offense.
>
> I get it. C is everywhere, everybody pushes it. It has some nice
> features and "can be" relatively portable. The syntax leaves some
> things to be desired, but overall it's not that bad. But it's also not
> my favorite. Still, it is so universal and popular that you almost
> can't ignore it. Almost.

pretty much.

whether or not a person "likes" C doesn't really matter all that much,
given it (and other more-or-less related languages) are so common as to
be largely inescapable.

my general policy here is to just "go with the flow" and use "whatever
works". I personally find both "promoting" and "opposing" things to be
largely ineffective and generally unproductive.

I think another thing is partly because I don't really tend to see
"change"/"novelty" or "perfection"/"elegance" as "intrinsically
valuable", and instead try to optimize for "whatever is most likely to
be the most effective".

oddly, some people seem to think that I oppose change, but I don't
really think this is the case.


the general result of this is my continued use of C and Makefiles and
similar, largely because there is not much to really gain from other
options, nor much to justify the large up-front costs of switching to
other technologies.


likewise goes for the use of C-style syntax (in the looser sense) for my
own language:
sure, not everyone likes it, but in all, there doesn't seem to be any
"clearly better" options, and I think the number of people who actively
dislike C-style syntax is much smaller than the number of people who
either don't care or who would prefer a "generally familiar" syntax if
given a choice in the matter.

so, it seems likely that there is likely some value in "maximizing for
mediocrity" in many regards.

otherwise, it likely amounts to a bit more of a "love-hate" game, where
maybe some people really like something, and most other people think it
isn't very good, with the most likely outcome being that a larger
majority of people actively dislike it more than the main alternative:
that the majority of people regard it with indifference.

not that this can't also be useful, but there is likely some need for
strategy in terms of what things are generic and which ones are novel,
such that there is more of a sense of "value added" or "style" than of a
general sense of "just what the hell is this and why should I care?".


many other things mostly boil down to cost/benefit tradeoffs, with the
open question of "how do the costs of the solution compare with those of
the original problem?". if the "solution" does more harm than the
original problem, is it really a good tradeoff?

( decided to leave out more detailed commentary, like dynamic vs static
types, and manifest types vs type-inference, as this got a bit long. )

but, yeah, it seems to me that the design choices made by many
mainstream languages are somewhere near the local optimum in many regards.

>>> 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.)
>>
>> This is what I work with so it's what I know, like and use. Please remember
>> the subject line and don't keep trying to sell me specific stuff or at least
>> if you do keep trying don't blame me for not buying. I was looking for
>> books, not software anyway. That's what the post was all about but for some
>> reason the replies mostly intermingled UNIX and C evangelism with a few
>> condescending insults from the usual snobs and a couple of pretty good
>> on-topic answers. Embarassing signal to noise ratio on this but I guess that
>> was expected given the audience. Try to swing a dead cat without hitting a
>> UNIX or C groupie on the internet...not easy.
>
> Yes, I hate to say it, no offense intended to anyone, yes *nix is semi-
> popular, but the constant propaganda of "Linux Linux Linux" is 1000x
> overblown (and they often hide behind "POSIX") and can be annoying.
> Not so much that it's so bad, but it's often not portable enough or is
> really complicated and messy. Not great for anyone using another
> "lesser" OS. You will not find a lot of Linux users who care about
> other OSes. I don't know why. So it's not always easy to share code.

yeah, I have noticed as well.

many FOSS projects especially seem to focus primarily or solely on
Linux, and often make little or no attempt to support other OS's (such
as Windows).

many will instead claim that it is Windows and Windows developers who
are all intent on writing non-standard and non-portable code, or using
an OS which is (somehow) actively hostile to FOSS code working, or similar.


in my case, I write code mostly on Windows and can fairly effectively
compile it both on Windows and Linux.

in general, I do so mostly by trying to write "generally portable" code
(mostly avoids using OS or compiler-specific features without good
reason, generally has fallback cases, ...).

so, for example, while the project uses plenty of OS-specific features,
and ASM code, pretty much all of it is (more or less) optional (a lot is
still "functionally relevant" though, so without it, a lot of stuff
wouldn't really work correctly).


I also personally just use raw makefiles (manually written per-target),
personally seeing this as a "lesser evil" in many regards to
automake/autoconf, which has the bad habit of not really working on Windows.


<snip>

not much comment.

> I sympathize with you, lots of people tend to drop "older" languages
> in lieu of Java or C# (ugh, why?). Seriously, it's kinda horrific. For
> instance, Andrew Appel has some compiler books (and teaches a course),
> but nowadays he seems to focus on Java (whereas older editions used C+
> + or C, which I would almost prefer for simplicity, even though they
> aren't my languages of choice). He doesn't have a book online, but I'm
> just telling you for comparison.

yeah.

lots of people tend to go for whatever is the newest and most popular
language, and there seems to be a fairly common mindset of "newer is
better".



<snip>

still not much to comment on.

(and somehow I didn't notice until now that this post was in
comp.lang.misc rather than comp.compliers, grr... I selectively snipped
for nothing...).


ok, I will add then:
I don't really like lex/yacc either, so I tend to just use hand-written
recursive descent parsers.


(wrote some stuff about my own VM, but decided to leave it out as it
looked to much like hijacking the thread...).

[Fritz Wuehler]

On Sat May 5 18:56:19 2012 rug...@gmail.com wrote:

Hello rugxulo, why don't you post through a news server? I enjoy reading
your posts, you have a lot to say and a good writing style. Unfortunately I
never see them anymore since I killfile all google posts like all good
netizens.

> I get it. C is everywhere, everybody pushes it. It has some nice features
> and "can be" relatively portable. The syntax leaves some things to be
> desired, but overall it's not that bad. But it's also not my
> favorite. Still, it is so universal and popular that you almost can't
> ignore it. Almost.

Well yes, I can as long as I don't talk to UNIX or PC people. It's a shame
but true. I have been working since 1975 and haven't written a line of C or
C++ or Java yet.

> Yes, I hate to say it, no offense intended to anyone, yes *nix is semi-
> popular, but the constant propaganda of "Linux Linux Linux" is 1000x
> overblown (and they often hide behind "POSIX") and can be annoying. Not so
> much that it's so bad, but it's often not portable enough or is really
> complicated and messy. Not great for anyone using another "lesser" OS. You
> will not find a lot of Linux users who care about other OSes. I don't know
> why. So it's not always easy to share code.

Sharing code is not something I do or something I want from anybody else. I
would like to hear how people look at different problems, more info is
usually a good thing. I found most of those views don't work in my
environment though so the interest is mostly academic but that is ok too.

I don't like Linux or UNIX. I think they're ok desktop OS but they're not
good OS from a technical perspective. I know many people think they are but
when that is all you know your opinion isn't that valuable. When all you
have to choose is UNIX or Windows then yeah, I think UNIX is better in most
areas but I really don't care since I am not a UNIX or Windows fanboy and
what happens with those OS doesn't affect me since I don't work with them. I
don't like Windows from a user point of view but I haven't ever looked at
the internals so I really can't say anything about it except from outside
impressions. Which are not good.

> Yeah, I don't know what your OS provides.

Here is the home page of the OS:

http://www-03.ibm.com/systems/z/os/zos/

This is the entire manual collection for the latest release of z/OS. It
includes most of what is available (672 manuals) but doesn't include
information on compilers except for C (but it does include the runtime
information, oddly). The other manuals (COBOL, PL/I, FORTRAN) have separate
home pages.

http://www-03.ibm.com/systems/z/os/zos/bkserv/r13pdf/index.html

Here is the Architecture Manual for the System Z CPU:

http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr008.pdf

The above manual explains the system architecture and facilities and is
where the CPU is defined. It covers registers, addressing modes, etc. It is
the ISA description. It is produced and owned by IBM, unlike other ISAs that
are standardized so one company gives you all the info on the OS and
hardware. To me this is much better than most other OS where you have an ISA
specification, library specification, assemblers, compilers, etc, POSIX
etc. all specified by external bodies and the resulting mayhem of
documentation. You have to go to ten companies to get all the doc you need
and there are always big holes where each company says it's not their
responsibility to document something or refers you to standard that cost 300
bucks to get a printed copy for each of ten standards you need. With z/OS
everything is presented by one company with one documentation standard. Once
you get to know the manual system you can find anything and everything is
presented in the same style. Very nice.

Here are the Programming Interfaces for Unauthorized Programs (Applications
programs):

Assembler Services Guide is an overview of the various services applications
programs can use.
http://publibz.boulder.ibm.com/epubs/pdf/iea2a6b0.pdf

The next manuals are detailed descriptions of how to use each of the services.
http://publibz.boulder.ibm.com/epubs/pdf/iea2a7b0.pdf
http://publibz.boulder.ibm.com/epubs/pdf/iea2a9c0.pdf

Here are the Programming Interfaces for Authorized Programs (Systems
software):

Authorized Assembler Services Guide as above but contains additional
information on features and extensions only allowed to systems software.
http://publibz.boulder.ibm.com/epubs/pdf/iea2a8c0.pdf

and Reference manuals showing the details of how to invoke each specific
service:
http://publibz.boulder.ibm.com/epubs/pdf/iea2a1b0.pdf
http://publibz.boulder.ibm.com/epubs/pdf/iea2a2c1.pdf
http://publibz.boulder.ibm.com/epubs/pdf/iea2a3b0.pdf
http://publibz.boulder.ibm.com/epubs/pdf/iea2a4b0.pdf


The next manual describes how to use facilities like address spaces and data
spaces as well as the new 64 bit memory management services
http://publibz.boulder.ibm.com/epubs/pdf/iea2a580.pdf

The next two manuals describe the program linker and loader and the APIs
http://publibz.boulder.ibm.com/epubs/pdf/iea2b1b0.pdf
http://publibz.boulder.ibm.com/epubs/pdf/iea2b2b0.pdf

The next two manuals describe the High Level Assembler Language in a
Programmer's Guide and Language Reference. The first one explains how to use
the assembler and the second one explains the assembler language. Nobody
besides IBM produces such clear, useful documentation. The other assembler
manuals I have seen don't come close.
http://publibz.boulder.ibm.com/epubs/pdf/asmp1020.pdf
http://publibz.boulder.ibm.com/epubs/pdf/asmr1020.pdf

There are more books on the assembler but these two above are the main ones.

This is one of many Data Areas manuals that describes the control blocks
used by the OS and other MVS products that run under the OS. The OS is not
open source but most of the control blocks are described so we can write
systems software that people will buy
http://publibz.boulder.ibm.com/epubs/pdf/a3208532.pdf

This is a manual that describes System Codes (abnormal termination codes)
http://publibz.boulder.ibm.com/epubs/pdf/iea2h7c1.pdf

This is one of several manuals that describes various error codes given by
components of the OS and products that run under it. Each error on z/OS or
the products that run under it are completely and consistently
documented. No oops or sorry messages, all have a prefix to let you know
which product or component detected the error, a number that specifies the
error exactly, and return and reason codes that describe the specific error
and how to fix it or how to report it to IBM or the software product team or
vendor.

This is a good sampling of manuals to get started with. It will take you
probably less than 10 years to go over this material, then you can review
the other 660 or so manuals. But they are interesting because they show you
an OS written in assembler with assembler interface, how nice the ISA and
system are, and how nice it is to have all the doc in one format, in one
place, written by people who actually created all of it. All the header files
are in assembler and PL/X (a high level assembler) and it really makes
working on this OS enjoyable. On UNIX or Windows and most other OS if you
want to write assembly language you have to beat your head against C header
files and C syscalls etc. And nobody offers this quality and coverage of doc.

> I think you mentioned before liking Ada (and since you mention Algol-W
> below, I guess that makes you Wirth-ian). I sympathize.

I like Ada because of the discipline but I like anything designed well. I don't
think I ever used ALGOL-W although I did use several ALGOL variants long
ago. The ALGOL-W discussion in this thread was because of something somebody
else said.

> Your best bet will be going the Wirth route, which means Pascal or
> similar. FreePascal is pretty good, but I don't know how easy (or not) it
> would be to cross-compile to your target.

It's probably out of the question since it is boostrapped in Pascal, unless
there is a Pascal compiler for z/OS or earlier that is good enough to
bootstrap FPC. And then there is the issue of not having libc available. I
ASSume FPC uses libc but maybe I am wrong. There probably is some POSIX
library available somewhere on z/OS but I haven't ever used it because not
much is done in C on z/OS and nothing we write uses it. I am sure there is
one in the UNIX that comes built into z/OS but many people prefer not to use
that from the main OS, either running everything natively or running
everything under the UNIX portion. I haven't used it but I understand it's a
full POSIX UNIX environment.

> So you don't like yacc and lex, I don't blame you. I guess the best
> "language agnostic" alternative would be Coco/R, for LL(1) I suppose. And
> Pat Terry has a book online about compilers using it. Coco/R has been
> itself ported to various languages: Pascal, Ada, Modula-2, Java, C ++,
> etc. It's quite funny, actually!

It's not that I don't like yacc or lex, I have no idea what they are. I do
know I don't use anybody else's code or tools except for the OS and
assemble. It's one of the things I like about what I work on. I don't have
to depend on tons of layers of broken crap. Everything works, everything is
documented. Everything makes sense. With UNIX it's all legacy burden, same
thing with Intel. I'm sure Coco is just as much impossible to use on z/OS as
yacc or lex. But thanks for the links. I have his book but I haven't gone
over it.

> I sympathize with you, lots of people tend to drop "older" languages in
> lieu of Java or C# (ugh, why?). Seriously, it's kinda horrific. For
> instance, Andrew Appel has some compiler books (and teaches a course), but
> nowadays he seems to focus on Java (whereas older editions used C+ + or C,
> which I would almost prefer for simplicity, even though they aren't my
> languages of choice). He doesn't have a book online, but I'm just telling
> you for comparison.

I have those books. I just don't know how helpful they would be since
they're all in languages I don't use or want to use. I keep wanting to like
ML or OCaml but they're just too damnned ugly and have wierd runtime
issues. That's another thing I like about assembler, no runtime!

> http://www.cs.sjsu.edu/~mak/CS153/index.html

Thanks, I'll have a look. And thanks for the other links as well.

> There's also Welsh's "standard" [old] Pascal compiler implementation book
> from the '80s, but it seems hard to find and fairly expensive. Plus,
> "classic" Pascal is heavily shunned these days, and I'm not sure how
> useful that is (I don't have it, and writing a standard Pascal compiler in
> standard Pascal may not be useful to you unless you want to use GCC-based
> GPC, heh, which I doubt, though it is a nice compiler, just hard to

> bootstrap!). You'd do better, IMO, to focus onP5 (P4 brought up to full

> standard Pascal), which is documented and available online and is public
> domain.

We do have a really fantastic PL/I compiler available and I don't know
anything a Pascal-derivative could do that this particular PL/I couldn't so
I don't see the point. I like the assembler so much I rarely have use for
anything else. Part of the idea is for me to think of something that would
be useful beyond the assembler, but PL/I and COBOL are so good there isn't
anything more I could ask for. I'll go over the Wirth stuff because it's
interesting from a historical view. He seems to have laid the foundations
for lots of interesting stuff, even if he himself was actually never
involved with any of the successful parts. It's kind of weird, but it shows
he had some idea what he was talking about because people took what he
started and turned it into very useful things. Maybe he is the kind of guy
who gets bored after he accomplishes something and then instead of refining
it and making it practical he goes on to the next thing.

> GWU / NYU Ada (83) exists too in C sources, though I know you despise
> that, but it's the only Ada that I could think of that is relatively
> useful and semi-portable. But I don't even know if it will compile, they
> used an old Intel compiler for DOS. But I'm sure it can't be that hard to
> port to OpenWatcom or whatever (famous last words!).

I'll look at the Ada 83 but as far as I know from the language itself it's
more than I can bite off. Ada is awfully hard on a compiler writer. And
again C sources won't help me much and OpenWatcom doesn't run on z/OS. There
is what is supposed to be a very good C compiler on z/OS and I have access
to it, I have just never used it.

> I know you've been interested in Forth, too. At least Forth has almost no
> syntax, so it should be easier to port.

I have been playing around with Forth a little and I am wondering if it
could be the "value-added" language that would be worth doing. I may
implement a fast cheap one just to play around with some other unrelated
ideas I have been working on. I don't know if I will or not. I find it
interesting for a few reasons. I like the idea of stack machines even though
Z architecture is not stack based and has no application stack. I don't
necessarily like the UNIX way stacks are implemented but stacks are
interesting in reducing complexity and storage references. And I like the
Forth idiom of building up stuff from the bottom. It's a very overlooked
under appreciated way of doing difficult things in code. People actually do
use this but not as far as they know. Most of the popular languages would be
nothing without their libraries. It's just that for those popular languages,
somebody else built up the language from small pieces. The kiddie coders
don't realize that. They just use all that stuff in the programs.

> But if you're interested in Wirth languages, grammar, LL(1), or something
> in the vein of Algol, you'll have to read up on some of Wirth's stuff (or
> similar). There is an old old Modula-2 subset out there somewhere written
> in old old Forth, though I've never tried it. FPC (Forth-83) for DOS
> supposed had a Pascal subset translator or whatever. Even old CAML Light
> had something similar. Maybe even UCB Logo did too, I can't remember. So
> you can write a compiler in anything, it just depends on how complex you
> want to make it!

I find Wirth difficult reading and I feel even though his designs seem
elegant and extensible they always seem to be impractical as presented. I
think somebody with more experience could get more out of it than I can at
this point. Thanks for your post. Consider getting more exposure by dumping
g00gloe groups, many people will appreciate it!

[Fritz Wuehler]

On Sun May 6 06:06:13 2012 cr8...@hotmail.com wrote:

> whether or not a person "likes" C doesn't really matter all that much,
> given it (and other more-or-less related languages) are so common as to be
> largely inescapable.

That is only true in the UNIX and PC world. In my work I have never had to
use C and it probably is only used for less than 1% of the work that people
in my business do. Otherwise I am sure I would use it. But you would be
surprised how many years I have been working as a developer and never used it.

> my general policy here is to just "go with the flow" and use "whatever
> works". I personally find both "promoting" and "opposing" things to be
> largely ineffective and generally unproductive.

There are people who like good tools and there are people who are happy with
Harbor Freight tools. I don't like crappy tools and I know the difference.
Aside from that as I said, C is too high level to do what I do and too low level
for anything else on the machines I work on. It is mostly not used and is
not an issue. It's only when I speak to people who think UNIX and Windows
are the only 2 OS in the world, they start trying to convert me to their
religion. Ain't going to happen. That makes them furious. Evangelists, go
figure. Oh btw since you said earlier you are somewhat religious I am not
using religion in real religional terms only referring to the idolatry of
the FSF and GPL groupies. There is real belief and false belief and I am
talking about the false ones.

> I think another thing is partly because I don't really tend to see
> "change"/"novelty" or "perfection"/"elegance" as "intrinsically valuable",
> and instead try to optimize for "whatever is most likely to be the most
> effective".

I agree change/novelty has no value, it is usually negative. I do see
perfection and elegance as essential to not feeling like you spent the day
or year or a whole career accomplishing nothing but mediocrity. That would
be pretty disturbing to look back and say to your self, you know I had an ok
job but I wrote crappy code and nobody cared. I write good code and it
matters. My tools also matter. I often have to work on products or pieces of
products I don't think are that great so the least I can do is implement
them the most elegant way possible. Then what happens is not my fault.

> the general result of this is my continued use of C and Makefiles and
> similar, largely because there is not much to really gain from other
> options, nor much to justify the large up-front costs of switching to
> other technologies.

I am sure that is true on PCs. But it is not true everywhere. Nobody would
think C isn't good for UNIX and probably Windows. But that doesn't mean it's
the universal solution. The assemblers for Intel are poor, even the best are
way below what IBM offers on z/OS. UNIX and Linux and Windows are written in
C (the latter C++, right?) so of course C is a good choice there.

> likewise goes for the use of C-style syntax (in the looser sense) for my
> own language: sure, not everyone likes it, but in all, there doesn't seem
> to be any "clearly better" options

If you had a good PL/I or PL/M available *and* the header files then maybe
you would like those better. Most people have to choose between C and
nothing else, so yeah C looks good then. What else have you seen that can
get the same job done?

> It's a , and I think the number of people who actively dislike C-style

> syntax is much smaller than the number of people who either don't care or
> who would prefer a "generally familiar" syntax if given a choice in the
> matter.

Right but most people are stupid and behave like sheep so what you said is
more a comment about human nature than what technology is good or bad. And
not caring kindof proves the people with that opinion shouldn't be
counted. Everything matters or else why do it. How can you waste your life
producing mediocre crap and have any sense of self worth or any sense of
making the world better? The world isn't improved by people writing crap
software and not caring about anything.

> so, it seems likely that there is likely some value in "maximizing for
> mediocrity" in many regards.

And on the above statement we disagree totally although I agree your view is popular.

> many FOSS projects especially seem to focus primarily or solely on
> Linux, and often make little or no attempt to support other OS's (such
> as Windows).

They often don't even attempt to support other mainstream OS like *BSD.

> in general, I do so mostly by trying to write "generally portable" code
> (mostly avoids using OS or compiler-specific features without good reason,
> generally has fallback cases, ...).

But to do that you have to know gcc isn't the only C compiler or even the
best C compiler. And 99.9% of the brainwashed FSF groupies don't know
that. You're ahead because you do.

> (and somehow I didn't notice until now that this post was in
> comp.lang.misc rather than comp.compliers, grr... I selectively snipped for
> nothing...).

I had to post it to an unmoderated newsgroup since very few people can
tolerate my variance with their religion...

> ok, I will add then: I don't really like lex/yacc either, so I tend to
> just use hand-written recursive descent parsers.

It's not that I don't like them it's that I have no idea what they are. I
will learn about parsing though. I know the basic stuff like what parsing a
command line means. I haven't thought about it but maybe parsing expressions
is only done by Ph.D computer science grads.

> (wrote some stuff about my own VM, but decided to leave it out as it
> looked to much like hijacking the thread...).

feel free, it is usenet :-)

Thanks for your posts BGB always enjoyable.

[BartC]

"Fritz Wuehler" <fr...@spamexpire-201205.rodent.frell.theremailer.net> wrote
in message
news:2eb99c87e6217fe3...@msgid.frell.theremailer.net...

> I don't like Linux or UNIX. I think they're ok desktop OS but they're not
> good OS from a technical perspective.

Some of us don't care. When I was selling software, 99% of my clients either
already had, or could buy anywhere, Windows desktop machines. The other 1%
had Linux or used Macs. That makes Windows a *good* OS from my point of
view. Actually, so long as it doesn't get in the way too much, I don't
really care about the OS.

> http://www-03.ibm.com/systems/z/os/zos/
> This is the entire manual collection for the latest release of z/OS. It
> includes most of what is available (672 manuals) but doesn't include

Doesn't really tell me much about z/OS, except that it looks even more of a
bloated monstrosity than I thought Unix and especially Windows were. 672
manuals!

> information on compilers except for C (but it does include the runtime
> information, oddly).

Oh, and that doesn't include most languages. Since you started in 1975, how
many have you got through so far?

> The next two manuals describe the High Level Assembler Language in a
> Programmer's Guide and Language Reference. The first one explains how to
> use
> the assembler and the second one explains the assembler language. Nobody
> besides IBM produces such clear, useful documentation. The other assembler
> manuals I have seen don't come close.
> http://publibz.boulder.ibm.com/epubs/pdf/asmp1020.pdf
> http://publibz.boulder.ibm.com/epubs/pdf/asmr1020.pdf

Sorry, can't make head or tail of those! I suppose if you've been immersed
in the same architecture for several decades, it might be clear to you.

> working on this OS enjoyable. On UNIX or Windows and most other OS if you
> want to write assembly language you have to beat your head against C
> header
> files and C syscalls etc. And nobody offers this quality and coverage of
> doc.

On Windows at least, you don't need to know or write any C. It's true the
APIs are described using a C interface, but that is fairly easy to
understand (C datatypes map directly to hardware) but in any case other
people have already done the work of creating Windows headers for ASM
programmers.

> It's not that I don't like yacc or lex, I have no idea what they are. I do
> know I don't use anybody else's code or tools except for the OS and
> assemble. It's one of the things I like about what I work on. I don't have
> to depend on tons of layers of broken crap. Everything works, everything
> is
> documented. Everything makes sense.

If it is compilers you're trying to work on, they are one of those
applications that are largely independent of OS, of user interfaces or
graphics, of almost anything. They have an input file, and an output file.
So you don't need to build on any 'crap' apart from file input and output,
and even then you can sometimes make do with console i/o instead.

> With UNIX it's all legacy burden, same
> thing with Intel.

Is this the same system z architecture that goes all the way back to the
system 360 from the 1960s?

> I'll look at the Ada 83 but as far as I know from the language itself it's
> more than I can bite off. Ada is awfully hard on a compiler writer.

About 50 man-years of effort apparently.

--
Bartc

[Marco van de Voort]

On 2012-05-07, BartC <b...@freeuk.com> wrote:
> On Windows at least, you don't need to know or write any C. It's true the
> APIs are described using a C interface, but that is fairly easy to
> understand (C datatypes map directly to hardware) but in any case other
> people have already done the work of creating Windows headers for ASM
> programmers.

(actually I think C headers are a pretty crappy way of describing an API,
since C headers in general are not machine translatable to something else.
Only certain (macroless and annotated) subset of C are)

About the actual discussion: I've been a professional PC developer for a
decade, and a hobby programmer on Dos/windows for more than a decade before
that, and have survived without C just fine.

And that includes a several flavours of Unix, and some clones like Linux,
Minix and non Unix POSIX like Haiku.

The most I did in C on PCs was making small programs to
printf("%d",sizeof(some struct));

[BartC]

"Marco van de Voort" <mar...@toad.stack.nl> wrote in message
news:slrnjqg4lm....@toad.stack.nl...

> On 2012-05-07, BartC <b...@freeuk.com> wrote:
>> On Windows at least, you don't need to know or write any C. It's true the
>> APIs are described using a C interface, but that is fairly easy to
>> understand (C datatypes map directly to hardware) but in any case other
>> people have already done the work of creating Windows headers for ASM
>> programmers.
>
> (actually I think C headers are a pretty crappy way of describing an API,
> since C headers in general are not machine translatable to something else.
> Only certain (macroless and annotated) subset of C are)

I meant more in the way that MSDN seems to use C function signatures to
describe an API function. Together with MS-specific types that you have to
create little programs as you describe...

> The most I did in C on PCs was making small programs to
> printf("%d",sizeof(some struct));
>

to find out exactly how they work.

> About the actual discussion: I've been a professional PC developer for a
> decade, and a hobby programmer on Dos/windows for more than a decade
> before
> that, and have survived without C just fine.

Same here, but because the languages I did use were my own, I needed some
way of communicating with rest of a machine. Having interfaces specified in
C was useful, because it's transparent enough (once you figure out what is
meant by 'long' or 'DWORD') to figure out how to talk to the OS. However
they then started using C++, which was pretty impossible.

Also, where I had the choice of using either C or Windows runtime functions,
I sometimes chose C's because they were a lot simpler (compare OpenFile or
the newer CreateFile with fopen, for example).

--
Bartc

[BGB]

On 5/7/2012 9:41 AM, Fritz Wuehler wrote:
> On Sun May 6 06:06:13 2012 cr8...@hotmail.com wrote:
>
>> whether or not a person "likes" C doesn't really matter all that much,
>> given it (and other more-or-less related languages) are so common as to be
>> largely inescapable.
>
> That is only true in the UNIX and PC world. In my work I have never had to
> use C and it probably is only used for less than 1% of the work that people
> in my business do. Otherwise I am sure I would use it. But you would be
> surprised how many years I have been working as a developer and never used it.
>

well, to some extent it is also on Mobile devices (phones, ...) but
competes there with Java and C# depending on the particular phone
(iPhone is mostly Objective-C, Android mostly Java, and Windows Phone
mostly C# and XNA and similar...).

>> my general policy here is to just "go with the flow" and use "whatever
>> works". I personally find both "promoting" and "opposing" things to be
>> largely ineffective and generally unproductive.
>
> There are people who like good tools and there are people who are happy with
> Harbor Freight tools. I don't like crappy tools and I know the difference.
> Aside from that as I said, C is too high level to do what I do and too low level
> for anything else on the machines I work on. It is mostly not used and is
> not an issue. It's only when I speak to people who think UNIX and Windows
> are the only 2 OS in the world, they start trying to convert me to their
> religion. Ain't going to happen. That makes them furious. Evangelists, go
> figure. Oh btw since you said earlier you are somewhat religious I am not
> using religion in real religional terms only referring to the idolatry of
> the FSF and GPL groupies. There is real belief and false belief and I am
> talking about the false ones.
>

I am primarily a PC developer though (Windows and Linux), and would
consider OSX if it were not so absurdly expensive.

I have looked some into Mobile developement, but have not done much as
there are a number of barriers that make mobile development problematic
at this point, and I would much rather be dealing with a more
homogenized environment.

>> I think another thing is partly because I don't really tend to see
>> "change"/"novelty" or "perfection"/"elegance" as "intrinsically valuable",
>> and instead try to optimize for "whatever is most likely to be the most
>> effective".
>
> I agree change/novelty has no value, it is usually negative. I do see
> perfection and elegance as essential to not feeling like you spent the day
> or year or a whole career accomplishing nothing but mediocrity. That would
> be pretty disturbing to look back and say to your self, you know I had an ok
> job but I wrote crappy code and nobody cared. I write good code and it
> matters. My tools also matter. I often have to work on products or pieces of
> products I don't think are that great so the least I can do is implement
> them the most elegant way possible. Then what happens is not my fault.
>

well, I aim to try to make reasonably good and solid code, but from a
design POV, things tend to be mostly mediocre, but as I see it mediocre
is a fairly good place to be.


I personally think at least that "in general" my VM architecture should
be both more elegant and more flexible than, for example, the JVM.
however, it also has its weak spots.


the language design is arguably less elegant, but partly because the
language wasn't aiming to be "simple" or "elegant", but rather to try to
look and act more like traditional "industrial strength" languages.

probably the VM internals are in some ways a bit more "expressive" and
"elegant" than the top-level language.


but, otherwise, if a person were to present a language looking like a
hybrid of Scheme and Self, almost no one would willingly use it (this is
closer to what I started out with, many years ago...).


so, over the years, layers were built on top:
C family syntax;
Class/Instance objects (sort of, it is a "hybrid model");
packages and import (internally, these are built largely on objects and
delegation).

>> the general result of this is my continued use of C and Makefiles and
>> similar, largely because there is not much to really gain from other
>> options, nor much to justify the large up-front costs of switching to
>> other technologies.
>
> I am sure that is true on PCs. But it is not true everywhere. Nobody would
> think C isn't good for UNIX and probably Windows. But that doesn't mean it's
> the universal solution. The assemblers for Intel are poor, even the best are
> way below what IBM offers on z/OS. UNIX and Linux and Windows are written in
> C (the latter C++, right?) so of course C is a good choice there.
>

yes, Linux is mostly plain C.
Windows is a mix of C and C++ AFAIK.

the main issue is that pretty much the only people with such IBM systems
are mostly companies and similar. they aren't something a typical
end-user is going to be using, nor something which the usual developer
will have much reason to target.

>> likewise goes for the use of C-style syntax (in the looser sense) for my
>> own language: sure, not everyone likes it, but in all, there doesn't seem
>> to be any "clearly better" options
>
> If you had a good PL/I or PL/M available *and* the header files then maybe
> you would like those better. Most people have to choose between C and
> nothing else, so yeah C looks good then. What else have you seen that can
> get the same job done?
>

well, long ago, there was Pascal...

a quick look shows PL/I looking like a very verbose language, which
isn't really my thing.


I have also before used languages like Scheme, Common Lisp, and Self.
apart from the syntax, these were the most direct semantic influences on
early forms of BGBScript (although cosmetically, the language has gone
much more in a "mainstream" direction).


although, at this point I have been left to reason that now
continuations are now pretty much entirely dead, and the language never
really did have all that great of macro facilities (what ones it does
have are currently rarely used anyways).

>> It's a , and I think the number of people who actively dislike C-style
>> syntax is much smaller than the number of people who either don't care or
>> who would prefer a "generally familiar" syntax if given a choice in the
>> matter.
>
> Right but most people are stupid and behave like sheep so what you said is
> more a comment about human nature than what technology is good or bad. And
> not caring kindof proves the people with that opinion shouldn't be
> counted. Everything matters or else why do it. How can you waste your life
> producing mediocre crap and have any sense of self worth or any sense of
> making the world better? The world isn't improved by people writing crap
> software and not caring about anything.
>

partly because changing the world isn't really my goal in life (whether
the world changes or stays the same doesn't really seem to be a big issue).

similarly, I don't really consider "human nature" to really be "a bad
thing to be fought against", but rather yet another cost/benefit
tradeoff, to be weighted along with many more-strictly-technical tradeoffs.

so, it is a world where nearly everything is cost/benefit tradeoffs,
ranging from technical concerns, to the behaviors of all the people
involved, to the various popular opinions and expectations, ...

>> so, it seems likely that there is likely some value in "maximizing for
>> mediocrity" in many regards.
>
> And on the above statement we disagree totally although I agree your view is popular.
>

yep.

well, in one sense, one does get "the most bang for the buck" by
pursuing mediocrity.

or a person could also be like "do your thing and follow the bling".

it would be like a musician choosing to mostly make gangsta rap as "this
is where the money is", and game-developers making a lot of FPS and
sports-themed games (as opposed to the once-popular RTS and RPG games), ...

so, whether or not any of this is "good" or not is largely a secondary
concern.

and, if popular preference changes, then the people producing content
will adapt and follow the market.

>> many FOSS projects especially seem to focus primarily or solely on
>> Linux, and often make little or no attempt to support other OS's (such
>> as Windows).
>
> They often don't even attempt to support other mainstream OS like *BSD.
>

yep.

>> in general, I do so mostly by trying to write "generally portable" code
>> (mostly avoids using OS or compiler-specific features without good reason,
>> generally has fallback cases, ...).
>
> But to do that you have to know gcc isn't the only C compiler or even the
> best C compiler. And 99.9% of the brainwashed FSF groupies don't know
> that. You're ahead because you do.
>

yeah, I use both GCC and MSVC.

>> (and somehow I didn't notice until now that this post was in
>> comp.lang.misc rather than comp.compliers, grr... I selectively snipped for
>> nothing...).
>
> I had to post it to an unmoderated newsgroup since very few people can
> tolerate my variance with their religion...
>

ok, just I hadn't noticed, and was engaging in the usual c.c writing and
editing magic such that the automatic filter and John don't complain
(otherwise I can just write whatever and all is well).

>> ok, I will add then: I don't really like lex/yacc either, so I tend to
>> just use hand-written recursive descent parsers.
>
> It's not that I don't like them it's that I have no idea what they are. I
> will learn about parsing though. I know the basic stuff like what parsing a
> command line means. I haven't thought about it but maybe parsing expressions
> is only done by Ph.D computer science grads.
>

I know what they are, I just personally don't care that much.

it is like having a dependency on a 3rd-party tool to maybe save writing
a little bit of code (for something that is rarely a significant amount
of code anyways), and meanwhile having the tool have a hard time with
things like context dependence or conditional syntax, ...

doesn't seem really worthwhile vs just writing a hand-rolled parser.

>> (wrote some stuff about my own VM, but decided to leave it out as it
>> looked to much like hijacking the thread...).
>
> feel free, it is usenet :-)
>
> Thanks for your posts BGB always enjoyable.
>

fair enough, but given the often lacking responses or commentary, I tend
to think that few people actually care all that much.


by now, I have forgotten what I was going to write about.
given my recent activities, it probably would have had something to do
with the type-system or similar (much of my recent activity on this
front has been about optimizing stuff and working on the type-system).

I had also looked again into the possibility of compiling C code to my
script VM, but at the moment this looks troublesome.

this is mostly related to the hassle of having to compile the C
frontend's ASTs into the current bytecode (the ASTs are significantly
different from those used by BGBScript), and deal somehow with the issue
of "the mountain of crud pulled in from the headers", which given the
current VM design would be a bit problematic (basically, there would be
a big pile of redundant crud shared between nearly every module
compiled, which in my VM can't simply be discarded like in a traditional
C compiler).

I have yet to think up an "ideal" solution to this problem (although
possible options include either compiling all of the source files as a
single giant module), or the development of more elaborate precompiled
header mechanisms, or devising some sort of post-compile "linker"
mechanism (which would essentially re-merge most of this stuff).

the "compile a single giant module" option would be technically simplest
to implement, whereas the "advanced precompiled headers" option would
likely pull off better results (and be much higher performance and
RAM-friendly), but would be technically more complex.

as of yet, little direct effort has been made in this direction (I have
gone as far as being able to get the ASTs from the C frontend into the
Script VM, but I would still need to write the logic to be able to
compile them effectively).

the particular target of interest here was the idea of experimentally
compiling Quake to work on the script VM, following the recent
observation that the VM's interpreter apparently currently runs faster
than much of the original HW the game was written to run on (more so, I
would probably compile a modified GLQuake, rather than use the SW renderer).

however, I had been working more immediately on trying to make the VM
itself more "generally solid" (and less likely to break / go really slow
/ start spewing garbage / ... if faced with this use case). I have thus
far not run anything so large/complex on the VM.

but, it still looks like a big complex issue, so I still don't really
know at this point...


or such...

[BartC]

"BGB" <cr8...@hotmail.com> wrote in message
news:jo9b8e$nik$1...@news.albasani.net...

> On 5/7/2012 9:41 AM, Fritz Wuehler wrote:

>> It's not that I don't like them it's that I have no idea what they are. I
>> will learn about parsing though. I know the basic stuff like what parsing
>> a
>> command line means. I haven't thought about it but maybe parsing
>> expressions
>> is only done by Ph.D computer science grads.
>>
>
> I know what they are, I just personally don't care that much.
>
> it is like having a dependency on a 3rd-party tool to maybe save writing a
> little bit of code (for something that is rarely a significant amount of
> code anyways), and meanwhile having the tool have a hard time with things
> like context dependence or conditional syntax, ...
>
> doesn't seem really worthwhile vs just writing a hand-rolled parser.

Yeah. I can't understand the preoccupation with parsing tools either. I
forget exactly how they work, but instead of:

- Writing a informal description of a syntax
- Writing a recursive descent parser (with a few kludges to iron out
ambiguities) with code to build your AST

you have to:

- Define your grammar in a formal language which has to be excruciatingly
exact
- Pass it through one of the tools enough times for it to stop complaining
- This then generates some source, probably (in my case) in the wrong
language (C?) ...
- ...which is just a framework that you then still have to fill in with most
of the code you need (iirc)

(and what happens when you run the tool again? Or the syntax changes; what
happens to all the code you've added?).

Anyway I don't understand why people bother. Lexing and parsing represent
about 1% of the effort of writing a compiler, especially if you're designing
a language too. My parsers get written once every few years, and
occasionally some bit of syntax changes, but the rest of my compilers
probably get completely rewritten half a dozen times over the same period.

--
Bartc

[Marco van de Voort]

On 2012-05-07, BartC <b...@freeuk.com> wrote:
>> (actually I think C headers are a pretty crappy way of describing an API,
>> since C headers in general are not machine translatable to something else.
>> Only certain (macroless and annotated) subset of C are)
>
> I meant more in the way that MSDN seems to use C function signatures to
> describe an API function. Together with MS-specific types that you have to
> create little programs as you describe...

Well MSDN used to use a subset of C. But to be honest, I actually learned
more C when working on Linux/FreeBSD than on Windows. My worst experience
was the FreeBSD startup code.

Nowadays I would use MSDN, but back when I learned windows programming, I used
translated Delphi win32 reference helpfiles and some books (like the "Tomes
Of Delphi" series). Only for win2k specific functions I needed MSDN.

The VCL abstracted the core 10% anyway.

>> The most I did in C on PCs was making small programs to
>> printf("%d",sizeof(some struct));
>
> to find out exactly how they work.

And to simply avoid mistakes wrt packing. I only did this for a windows
target last year btw.

I've maintained our microcontroller codebase in C the last 8 years though.

>> About the actual discussion: I've been a professional PC developer for a
>> decade, and a hobby programmer on Dos/windows for more than a decade
>> before
>> that, and have survived without C just fine.
>
> Same here, but because the languages I did use were my own, I needed some
> way of communicating with rest of a machine.

> Having interfaces specified in
> C was useful, because it's transparent enough (once you figure out what is
> meant by 'long' or 'DWORD') to figure out how to talk to the OS.

It's the procedural definition, rather than C. Most of the calls are not
even proper C (since they are stdcall)

Wouldn't it really be different if it were Pascal (like e.g. Classic Mac OS
in the early years actually was?)

More importantly, if you _wouldn't_ have used an own language, but rather a
fairly major other language (Delphi, VB come to mind), would you actually
have needed the raw interfaces much?

> However they then started using C++, which was pretty impossible.

If only because C++ ABIs remain murky. But that is a procedural API thing
again.

> Also, where I had the choice of using either C or Windows runtime functions,
> I sometimes chose C's because they were a lot simpler (compare OpenFile or
> the newer CreateFile with fopen, for example).

It is more logical to use the file I$/O that comes with your language.

[BartC]

"Marco van de Voort" <mar...@toad.stack.nl> wrote in message

news:slrnjqgfki....@toad.stack.nl...

> On 2012-05-07, BartC <b...@freeuk.com> wrote:

> It's the procedural definition, rather than C. Most of the calls are not
> even proper C (since they are stdcall)

That's just a calling convention. It's just part of what *has* to be in C,
if it's going to be used under Windows. My languages tended to use the same
convention, but it's one of those things you sort out once, then forget
about for years.

You had to take more care with callback functions; Windows assumes
(presumably) it's calling a Visual C function, which saves certain
registers. So your language has to do the same (which mine didn't, meaning
some inline asm in a few strategic places).

> Wouldn't it really be different if it were Pascal (like e.g. Classic Mac
> OS
> in the early years actually was?)
>
> More importantly, if you _wouldn't_ have used an own language, but rather
> a
> fairly major other language (Delphi, VB come to mind), would you actually
> have needed the raw interfaces much?

It would have meant less work certainly; anything involving a Windows API
(and a C one to a lesser extent) meant translating hundreds of #defines,
macros, structs and function declarations into an acceptable format for my
language. Fortunately a small subset of the thousands of functions was
enough for my needs.

But as for actually using a mainstream language for serious work, sorry I
can't remember the last time I did that. I guess the APIs are just presented
as part of the language that is being used, so you're not even aware of
calling foreign functions. I think you do learn more doing things the hard
way.

>> Also, where I had the choice of using either C or Windows runtime
>> functions,
>> I sometimes chose C's because they were a lot simpler (compare OpenFile
>> or
>> the newer CreateFile with fopen, for example).
>
> It is more logical to use the file I$/O that comes with your language.

Yes, but because I'm not programming bare hardware anymore, I have to access
i/o via the OS, and I chose to do this indirectly via the C runtime, and
this was done via wrappers to implement my idea of a file API.

--
Bartc

[Kaz Kylheku]

On 2012-05-07, BartC <b...@freeuk.com> wrote:

> Yeah. I can't understand the preoccupation with parsing tools either. I
> forget exactly how they work, but instead of:
>
> - Writing a informal description of a syntax
> - Writing a recursive descent parser (with a few kludges to iron out
> ambiguities) with code to build your AST
>
> you have to:
>
> - Define your grammar in a formal language which has to be excruciatingly
> exact

.. with kludges to iron out ambiguities!

> - Pass it through one of the tools enough times for it to stop complaining
> - This then generates some source, probably (in my case) in the wrong
> language (C?) ...
> - ...which is just a framework that you then still have to fill in with most
> of the code you need (iirc)

Hear, hear. I've regretted every time I used lex and yacc.
These tools generate bloated code which you have little control over.

One thing I hate is that you can't parse a sub-grammar. For instance, you can't
call yyparse to just parse an expression. There would have to be an interface
for getting the parser into the proper state first.

But this is trivially easy for a top-down parser. Just call the function that
parses an expression. Done.

[Fritz Wuehler]

"BartC" <b...@freeuk.com> wrote:

> "Fritz Wuehler" <fr...@spamexpire-201205.rodent.frell.theremailer.net> wrote
> in message
> news:2eb99c87e6217fe3...@msgid.frell.theremailer.net...
>
> > I don't like Linux or UNIX. I think they're ok desktop OS but they're not
> > good OS from a technical perspective.
>
> Some of us don't care. When I was selling software, 99% of my clients either
> already had, or could buy anywhere, Windows desktop machines. The other 1%
> had Linux or used Macs. That makes Windows a *good* OS from my point of
> view. Actually, so long as it doesn't get in the way too much, I don't
> really care about the OS.

I write OS stuff so what OS I work on is pretty important to me. But I
understand if you write apps you like whatever OS is popular. Depends what
layer you work in.

> > http://www-03.ibm.com/systems/z/os/zos/
> > This is the entire manual collection for the latest release of z/OS. It
> > includes most of what is available (672 manuals) but doesn't include
>
> Doesn't really tell me much about z/OS, except that it looks even more of a
> bloated monstrosity than I thought Unix and especially Windows were. 672
> manuals!

It's not bloated at all. Intel's manual set now just counting the basic set
without optimization etc. is about 4100 pages. The latest Z Principles Of
Operation is 1300 pages. z/OS has way more hardware capability than Intel
and the doc is 25% of the size. Another difference with z/OS is they
actually write good doc. Linux has basically no doc except what people feel
like writing. Windows has a lot of doc but Windows doesn't do 10% of what
z/OS does. Still it would be interesting to count up all their doc including API
manuals etc. You might surprise yourself. This is all included in the 672
manuals. I know it's a lot, but you have to compare apples with apples. Big
is not the same as bloated. z/OS is a real OS, it's not a toy for desktops
or workgroup servers. Fortune 1000 companies run on a single box.

>
> > information on compilers except for C (but it does include the runtime
> > information, oddly).
>
> Oh, and that doesn't include most languages. Since you started in 1975, how
> many have you got through so far?

What was your question?

> > The next two manuals describe the High Level Assembler Language in a
> > Programmer's Guide and Language Reference. The first one explains how to
> > use
> > the assembler and the second one explains the assembler language. Nobody
> > besides IBM produces such clear, useful documentation. The other assembler
> > manuals I have seen don't come close.
> > http://publibz.boulder.ibm.com/epubs/pdf/asmp1020.pdf
> > http://publibz.boulder.ibm.com/epubs/pdf/asmr1020.pdf
>
> Sorry, can't make head or tail of those! I suppose if you've been immersed
> in the same architecture for several decades, it might be clear to you.

Were you speaking about these two manuals specifically or what you saw on
the doc links page in general? The post you are responding to was addressed
to rugxulo because he expressed interest in it. I'm not surprised you can't
make head or tail of them but then if you wanted to I'm sure you could with
some guidance. It's all laid out very nicely but you do need to get to know
how it is laid out that is why I referenced the specific doc I did. At this
point I don't think anybody can learn this all. We learned it as it developed.
It was alot easier then. And there were less manuals but it also did less.
Quite alot of the doc is on optional stuff most people never touch. They
still document it in case anybody wants it. The core manuals for what each
person needs to do depend on his job. Nobody is expected to use the whole
set. There is doc for operators, systems programmers, applications
programmers, software vendors, and hardware maintenance.

> If it is compilers you're trying to work on, they are one of those
> applications that are largely independent of OS, of user interfaces or
> graphics, of almost anything. They have an input file, and an output file.
> So you don't need to build on any 'crap' apart from file input and output,
> and even then you can sometimes make do with console i/o instead.

I'm not sure how that can be since the code generation has to be for a
specific target and optimization is heavily target-based.

> > With UNIX it's all legacy burden, same
> > thing with Intel.
>
> Is this the same system z architecture that goes all the way back to the
> system 360 from the 1960s?

It's an evolution. Nothing better has come along so..

Anything written in the 1960s will still run but modern stuff won't run
backwards. The difference is UNIX is broken and has legacy burden, a lot of
it but not all has to do with Intel. IBM actually got it right the first
time and evolved things properly so for example 64 bit code doesn't have
twice the footprint of 32 bit code and you don't have to run your OS or all
your work in one mode like Intel mostly forces you to. Stuff like that where
Intel shit the bed is embarassing. IBM did everything brilliantly and you
can run 24, 31, and 64 bit code together, unlike UNIX/Linux where you can't
link 32 bit libraries with 64 bit code and vice versa.

[BartC]

"Fritz Wuehler" <fr...@spamexpire-201205.rodent.frell.theremailer.net> wrote
in message

news:909b25457b19978d...@msgid.frell.theremailer.net...

> "BartC" <b...@freeuk.com> wrote:

>> 672 manuals!
>
> It's not bloated at all. Intel's manual set now just counting the basic
> set
> without optimization etc. is about 4100 pages. The latest Z Principles Of
> Operation is 1300 pages.

I agree the Intel/AMD docs are now bloated, and that their processors are a
mess (the better ones never got popular). And the Z manual is surprisingly
readable (some good ideas to be gleaned from it even if I never get to use
one).

However, when I had to do some low-level work recently, I worked from an
instruction set summary on the last five pages of the original 8086
datasheet. This provided most of what I needed! I hardly ever go near the
official docs.

> is not the same as bloated. z/OS is a real OS, it's not a toy for desktops
> or workgroup servers. Fortune 1000 companies run on a single box.

It's dangerous calling any PC a 'toy'. A Ł200 netbook probably has more
computing power than any 1970s mainframe.

>> If it is compilers you're trying to work on, they are one of those
>> applications that are largely independent of OS, of user interfaces or
>> graphics, of almost anything. They have an input file, and an output
>> file.
>> So you don't need to build on any 'crap' apart from file input and
>> output,
>> and even then you can sometimes make do with console i/o instead.
>
> I'm not sure how that can be since the code generation has to be for a
> specific target and optimization is heavily target-based.

The compiler itself, as an application, has few requirements. You could
probably still run one from a paper teletype. It doesn't even need to run on
the same machine as the target.

I think you said you were familiar with the assembler on your system. Fine,
then a compiler will translate some source code (perhaps of a language that
you devise) in a file, to HLASM source code in another file. OS matters
really hardly come into it, not until you need to work on a runtime anyway,
but that's separate from creating a compiler.

--
Bartc

[Rugxulo]

Hi,

On May 8, 12:06 am, Fritz Wuehler

<fr...@spamexpire-201205.rodent.frell.theremailer.net> wrote:
> "BartC" <b...@freeuk.com> wrote:
> > "Fritz Wuehler" <fr...@spamexpire-201205.rodent.frell.theremailer.net> wrote
> > in message
> >news:2eb99c87e6217fe3...@msgid.frell.theremailer.net...
>

> It's not bloated at all. Intel's manual set now just counting the basic set
> without optimization etc. is about 4100 pages.

Presumably most of that is detailed explanations of all the system-
level stuff. The x86 instruction set isn't that complex, esp. if you
ignore the SIMD stuff.

> The latest Z Principles Of
> Operation is 1300 pages. z/OS has way more hardware capability than Intel
> and the doc is 25% of the size. Another difference with z/OS is they
> actually write good doc. Linux has basically no doc except what people feel
> like writing. Windows has a lot of doc but Windows doesn't do 10% of what
> z/OS does.

Which Linux? There are a billion incompatible distros. And Windows has
so many competing technologies too (Java, C#, HTML5+JS, C++), not
counting other deprecated stuff. It can definitely be confusing if you
let it.

> > If it is compilers you're trying to work on, they are one of those
> > applications that are largely independent of OS, of user interfaces or
> > graphics, of almost anything. They have an input file, and an output file.
> > So you don't need to build on any 'crap' apart from file input and output,
> > and even then you can sometimes make do with console i/o instead.
>
> I'm not sure how that can be since the code generation has to be for a
> specific target and optimization is heavily target-based.

He's basically saying the truth, though, you don't need anything more
than simple file I/O to write a compiler, e.g. the original Pascal
compiled itself.

http://www.standardpascal.org/p4.html

P4 is a Pascal subset (not to be confused with Pascal_S) that compiles
to bytecode. Then you run the bytecode in an interpreter. It was meant
to ease porting to other systems (and was done frequently). Of course,
being written in itself is questionable, but Pascal (being an Algol
descendant, at least in spirit) is readable, so translating by hand
was apparently considered not too difficult, once you understood it.
(Also p2c was later used to translate to C.)

More interesting would probably be "full" ISO 7185 Pascal, aka P5
(thanks to Scott Moore's work). This is all public domain, BTW.
Granted, dunno if you prefer this particular example, who knows, but
it's a working example, well-documented online with the book and
examples etc., and should be easy (or at least easier) to port than
most others.

> Anything written in the 1960s will still run but modern stuff won't run
> backwards. The difference is UNIX is broken and has legacy burden, a lot of
> it but not all has to do with Intel.

I doubt Intel is to blame for UNIX (tm). ;-) And believe it or not,
there isn't that much legacy in *nix, or at least Linux doesn't follow
it so closely that it refuses everything else.

> IBM actually got it right the first
> time and evolved things properly so for example 64 bit code doesn't have
> twice the footprint of 32 bit code and you don't have to run your OS or all
> your work in one mode like Intel mostly forces you to.

In fairness, Linux does have (optional) X32 ABI nowadays, though it's
very new so I'm not sure how much used it is yet. Also, the mode bit
is kinda true but can be worked around (VT-X), I think.

> Stuff like that where
> Intel shit the bed is embarassing. IBM did everything brilliantly and you
> can run 24, 31, and 64 bit code together, unlike UNIX/Linux where you can't
> link 32 bit libraries with 64 bit code and vice versa.

Yes, Linux can be frustrating, but some people love it. It's not bad,
just sometimes hard to use.

BTW, just to comment on two other (minor) things:

(quoting MarcoV): "The most I did in C on PCs was making small

programs to
printf("%d",sizeof(some struct));"

I'm no C guru, but don't forget that size_t doesn't always equal int.
So you should probably use C99's %z here. ;-)

And thinking of FreePascal ...

(quoting Fritz): "It's probably out of the question since it is

boostrapped in Pascal, unless there is a Pascal compiler for z/OS or
earlier that is good enough to bootstrap FPC. And then there is the
issue of not having libc available. I ASSume FPC uses libc but maybe I
am wrong."

I don't know how FPC is bootstrapped on new machines. I think they
cross-compile, but I'm not sure what they get started with. In any
case, it's probably still possible somehow, even if you have to
temporarily use p2c or similar. And no, FPC doesn't (by default) use
libc at all, it uses system calls directly and static compiles, even
on Linux (though you can change that).

"I'm sure Coco is just as much impossible to use on z/OS as
yacc or lex."

Well, the real problem is trying to bootstrap with a suitable language
and compiler, even if that is something you don't want to use full-
time. I guess that's your call, though, but most things indeed do
assume C or similar. I guess you can hand-translate stuff or just
rewrite from scratch once you understand it (which sounds like your
goal).

[Marco van de Voort]

On 2012-05-08, Rugxulo <rug...@gmail.com> wrote:

> Yes, Linux can be frustrating, but some people love it. It's not bad,
> just sometimes hard to use.
>
> BTW, just to comment on two other (minor) things:
>
> (quoting MarcoV): "The most I did in C on PCs was making small
> programs to
> printf("%d",sizeof(some struct));"
>
> I'm no C guru, but don't forget that size_t doesn't always equal int.
> So you should probably use C99's %z here. ;-)

Boring. I think I'll notice when weird numbers fall out.

> And thinking of FreePascal ...
>
> (quoting Fritz): "It's probably out of the question since it is
> boostrapped in Pascal, unless there is a Pascal compiler for z/OS or
> earlier that is good enough to bootstrap FPC.

Somebody on FPC is working on an AIX port. (PPC platform).

Some people mentioned interested in the older IBM systems in those threads,
but it sounded like there were major hurdles.

> And then there is the issue of not having libc available. I ASSume FPC
> uses libc but maybe I am wrong."

It depends on the platform. On Solaris, BeOS and Darwin it uses libc by
default, on other platforms (Windows, OS/2, Linux, FreeBSD, OpenBSD, NetBSD) it does not.

The Unices and pseudo unices (SkyOS in the past, BeOS/Haiku) all share a
base Unix RTL. The BSDs (including OS/X-darwin) share another common
subset.

I assume the AIX port does however, since it is by the Darwin (OS/X)
maintainer.

> I don't know how FPC is bootstrapped on new machines. I think they
> cross-compile, but I'm not sure what they get started with

FPC is always compiled by the stable version before the version you are
compiling.

When I ported, I always crosscompiled to target assembler, and then linked on
target. (to rule out trouble with cross versions of binutils)

> In any case, it's probably still possible somehow, even if you have to
> temporarily use p2c or similar.

I don't know why you think you need anything else? If I crosscompile GCC I
don't run it through C2pas either ? :-)

> And no, FPC doesn't (by default) use libc at all, it uses system calls
> directly and static compiles, even on Linux (though you can change that).

On Linux it does (mostly to counter the various versions of libc in use by
various distributions, though that is less nowadays than it used to).

> Well, the real problem is trying to bootstrap with a suitable language
> and compiler, even if that is something you don't want to use full-
> time. I guess that's your call, though, but most things indeed do
> assume C or similar.

Depends on if there is a GCC for it or not. If there is only an old K&R
system C and they want to charge you an arm and a leg for something newer,
then you have a problem with all fancy C99isms.

But note that is only a problem for systems without own codegenerators, that
borrow the C one, like scripting languages. For self hosting systems with
own codegenerators like FPC, it is not even relevant, except for a reference
of "how it is done".

[BGB]

On 5/8/2012 8:31 AM, Rugxulo wrote:
> Hi,
>
> On May 8, 12:06 am, Fritz Wuehler
> <fr...@spamexpire-201205.rodent.frell.theremailer.net> wrote:
>> "BartC"<b...@freeuk.com> wrote:
>>> "Fritz Wuehler"<fr...@spamexpire-201205.rodent.frell.theremailer.net> wrote
>>> in message
>>> news:2eb99c87e6217fe3...@msgid.frell.theremailer.net...
>>
>> It's not bloated at all. Intel's manual set now just counting the basic set
>> without optimization etc. is about 4100 pages.
>
> Presumably most of that is detailed explanations of all the system-
> level stuff. The x86 instruction set isn't that complex, esp. if you
> ignore the SIMD stuff.
>

most of it is because I think they describe instructions like:
first page, has the instruction forms;
subsequent pages, basic information about the instruction.

if it takes 3 pages of mostly whitespace to describe a single
instruction, it follows that there will be a lot more pages...


if compactness were more of a concern, they would probably put all of
the information about an instruction on a single page, or hell, even
list off multiple instructions in a single table.

it probably depends. a static compiler can probably be done with little
more than file IO.

a VM involving JIT may need a bit more to be effective (mmap and libdl
on Linux, VirtualAlloc/OpenLibrary/GetProcAddress/... on Windows).


granted, the logic written here may get a bit complex, hence why many
people use libraries for things.

things like HW accelerated 3D rendering require a good deal more though,
such as an API along the lines of OpenGL.

>> Anything written in the 1960s will still run but modern stuff won't run
>> backwards. The difference is UNIX is broken and has legacy burden, a lot of
>> it but not all has to do with Intel.
>
> I doubt Intel is to blame for UNIX (tm). ;-) And believe it or not,
> there isn't that much legacy in *nix, or at least Linux doesn't follow
> it so closely that it refuses everything else.
>

yep.


Windows has a lot more legacy.

Linux is a lot more prone to be like "whatever, now your old code is
broken...", so occasionally code intended for older versions of Linux
needs to be ported to newer versions.

binary compatibility between distros also rarely works (which is
different from Windows, where it nearly always works, except maybe for
very old apps).

>> IBM actually got it right the first
>> time and evolved things properly so for example 64 bit code doesn't have
>> twice the footprint of 32 bit code and you don't have to run your OS or all
>> your work in one mode like Intel mostly forces you to.
>
> In fairness, Linux does have (optional) X32 ABI nowadays, though it's
> very new so I'm not sure how much used it is yet. Also, the mode bit
> is kinda true but can be worked around (VT-X), I think.
>

the CPU itself can run 64, 32, and 16 bit code all at the same time.

apparently, in the case of Windows, MS just didn't really feel like
porting NTVDM to newer Windows, so they dropped support for it (leaving
only 32 and 64 bit code).

V86 mode was dropped by the CPU, and MS didn't bother including any sort
of emulator.


I am not really sure what is going on in Linux land, more likely they
just didn't bother supporting both modes at the same time.

X32 is nifty mostly in that it allows 32 bit code to exist without
needing mode changing, and the compiler can be (probably) smart enough
to glue around some other issues.

more generally, it would allow more easily using extended registers and
64-bit integer math from 32-bit code. however, it is, technically, still
a bit of a hack.

>> Stuff like that where
>> Intel shit the bed is embarassing. IBM did everything brilliantly and you
>> can run 24, 31, and 64 bit code together, unlike UNIX/Linux where you can't
>> link 32 bit libraries with 64 bit code and vice versa.
>
> Yes, Linux can be frustrating, but some people love it. It's not bad,
> just sometimes hard to use.
>

yeah.

a similar issue sort of exists on Windows, but it is theoretically
possible to glue different-sized code together (by using the same
trickery that WoW64 uses internally, namely switching between 32 and
64-bit mode via far jumps).

the issue is that it is apparently "not generally worthwhile" to do so,
given that data structure layout and pointer-size will differ, ...
meaning a need for complex/awkward "thunks" and "shims" to allow the
code to interface, as well as data marshaling tricks, ...


I suspect most of the issues are probably mostly due to how the
compilers and ABIs traditionally work, rather than being the fault of
the CPU architecture per-se.

otherwise, the ABI would need something like having it be up to the
loader to determine things like structure layout (sort of like in the
JVM, where the VM itself manages things like physical class layout, ...).

[Marco van de Voort]

On 2012-05-08, BGB <cr8...@hotmail.com> wrote:
> the CPU itself can run 64, 32, and 16 bit code all at the same time.

Do you have a reference for that? I thought it was either 64/32 or 32/16,
but never 64/32/16 without the 16-bit being emulated.

[Rod Pemberton]

<comp...@is-not-my.name> wrote in message
news:woglngji...@mixnym.net...
> glen herrmannsfeldt <g...@nospam.ugcs.caltech.edu> wrote:
...

"The best of 'Fritz' ..."

> [...] you can say whatever John lets you, it's his mailing list. [and he

> has proven that by censoring the thread (as usual) so this is going to
> comp.lang.misc]

ROFL!

Was it a *permanent* kick or just that post? I just can't understand how
you managed to annoy John ... He's such a nice guy. He seems to like "old
farts" too, especially those who discuss ancient history like old IBM.
Maybe, it had something to do with the "biting" and sarcastic commentary?
Well, you were probably on a "short leash" anyway because of a non-real
email address provided by your remailer ...

> Aside from that as I said, C is too high level to do what I do and too
> low level for anything else on the machines I work on.

Lol! That's a complete contradiction! Well, if you're a programmer it is,
which you've led most you converse with to believe that you are ... You
love messing with some peoples heads, don't you? That statement only makes
sense if a) you were to use C to do a non-programming task like writing text
manuals, and b) you exalt IBM's z/OS programming languages and capabilities
into the stratosphere. PL/I is as powerful as C, no more, and probably
somewhat less. After bashing C, you go on to tout PL/M, which is much
lower, and then tout PL/I which is no better:

> If you had a good PL/I or PL/M available *and* the header files then
> maybe you would like those better.

This makes no sense after you bashed C ...

> In my work I have never had to use C and it probably is only used for less
> than 1% of the work that people in my business do.

Yes, I agree.

Diamond brokers and coal miners have no use for C ...

> I have been working since 1975 and haven't written a line of C or C++ or
> Java yet.

Yes, I agree.

Those working road construction wouldn't have any need for C either ...

You haven't exactly stated that you're a programmer either ... yet. As far
as we know, you're a technical writer, or in management, and probably
retired. Given your supposed initial age of working (1975), you likely took
a buyout from IBM once you got near or into your early 60s, probably just
prior to 40 years of seniority.

For example, in the following statement of yours, you never state that
you're the one "working on this OS", or that you're actually programming it.
You only state that those features make it enjoyable. To whom? You? Some
programmer who told you so? A customer?

> All the header files are in assembler and PL/X (a high level assembler)

> and it really makes working on this OS enjoyable.

Many of your statements are vague and leading like that one. I can honestly
say it's a joy to work on Windows 98. It has a complete set of APIs and
headers. It has a variety of good compilers and tools. However, while all
that's true, it doesn't mean I've ever written a lick of code for Windows.
I haven't. My statements, just as yours, was leading and vague unless you
know the truth or read between the lines.

> I write OS stuff so what OS I work on is pretty important to me.

I actually considered that you ran a Markov Generator for that one.

... again with the "write" instead of "code" or "program" ...

If I were an employee of MS and wrote technical manuals for Windows, then
what OS I worked on would be pretty important to me also. Perceived,
careful word selection tends to lead others to the truth, eventually. Keep
talking.

> But I understand if you write apps you like whatever OS is popular.

I'll give you the benefit of the doubt on that. I'll assume you actually
meant "code" or "program", not "write" - as in an English paper ... So, you
do intend to code your Forth, which is an app typically, on a popular OS?
Congrats! You've progressed, immensely.

Curious, have you ever heard of "Neuro-Linguistic Programming"? Have you
ever seen video of it being used on unsuspecting people? They use
contradictory or confusing language to produce mental confusion or a
hypnosis like state. Basically, a "brain fart" if you will. If not, you
should read up on it ... I'm just wondering where you picked up NLP? Was it
from "handling" IBM management?

http://en.wikipedia.org/wiki/Neuro-linguistic_programming


Rod Pemberton

[BartC]

"Rod Pemberton" <do_no...@notemailntt.cmm> wrote in message
news:jodk8d$1pd$1...@speranza.aioe.org...
> <comp...@is-not-my.name> wrote in message

>> Aside from that as I said, C is too high level to do what I do and too
>> low level for anything else on the machines I work on.
>
> Lol! That's a complete contradiction!

I partly agree. When I need to go to low-level, then C doesn't go low
enough. But for most other programming, it's far too low-level. In fact at
the minute I need to use two separate languages for those two requirements
(or three if you count inline assembly as a separate language).

> Well, if you're a programmer it is,
> which you've led most you converse with to believe that you are ...

I don't think he has stated that in so many words, but he has said:

" I have written a few interpreters ..."

Apparently, he wants to go to the next step towards creating a compiler, but
is coming up with a large number of excuses why he can't; for example he
goes on to say:

" ... and I thought about winging it but I
realize there is a science to compiling and there are right and wrong ways
to do things. I would like to do things the right way but maybe with my
weak background and broken undergrad CS degree that is expecting too much."

Then there is getting exactly the right textbooks, choosing exactly the
right language to compile, just the right implementation language, etc. (See
the thread on comp.compilers from 17.Apr.2012.)

Many of us don't understand this, but perhaps, working exclusively in the
corporate IBM world for so long, where a 'compiler' is a huge, intimidating
piece of software (and perhaps a 'computer' is still a huge, intimidating
and *expensive* array of cabinets in an air-conditioned room), and where
everything has to be done by the book, perhaps it can be seen as a big
undertaking.

--
Bartc

[BGB]

I thought so too originally.

actually, only v86 mode was dropped, meaning that only MS-DOS programs
would have required emulation, but not 16-bit Windows apps.

apparently, MS concluded that it would have been too much pain/effort to
keep 16-bit stuff still working, so this much is MS's fault.


in the "System Programming Guide" of the Intel docs:
4.8.3.1: (IA-32e Mode Call Gates), it mentions the possibility of having
16-byte descriptors in the same descriptor table (such as GDT) as 32-bit
and 16-bit entries.

several other rules are stated regarding calls between 16, 32, and 64
bit code.

3.4.5: Segment Descriptors
L=0, D=0: 16-bit segment
L=0, D=1: 32-bit segment
L=1, D=0: 64-bit segment
L=1, D=1: reserved

...

[Nomen Nescio]

Marco van de Voort <mar...@toad.stack.nl> wrote:

> On 2012-05-07, BartC <b...@freeuk.com> wrote:
> > On Windows at least, you don't need to know or write any C. It's true the
> > APIs are described using a C interface, but that is fairly easy to
> > understand (C datatypes map directly to hardware) but in any case other
> > people have already done the work of creating Windows headers for ASM
> > programmers.
>
> (actually I think C headers are a pretty crappy way of describing an API,
> since C headers in general are not machine translatable to something else.
> Only certain (macroless and annotated) subset of C are)

I don't mind the C headers so much in principle after all they can write
their OS however they want. Excessive typedefs do make it very difficult to
follow when all you want to do is understand what they actually mean, as you
said. You can't translate all that without a C compiler. I realize there are
some copies of syscalls and libc calls translated to assembler headers but
that doesn't always help either because no two Intel assmblers are alike and
many have no support for structures and then even if they do C has its own
alignment rules. And those translations aren't official so if they're wrong,
oh well. It's an ugly pain in the ass.

[BGB]

On 5/9/2012 5:48 AM, BartC wrote:
> "Rod Pemberton" <do_no...@notemailntt.cmm> wrote in message
> news:jodk8d$1pd$1...@speranza.aioe.org...
>> <comp...@is-not-my.name> wrote in message
>
>>> Aside from that as I said, C is too high level to do what I do and too
>>> low level for anything else on the machines I work on.
>>
>> Lol! That's a complete contradiction!
>
> I partly agree. When I need to go to low-level, then C doesn't go low
> enough. But for most other programming, it's far too low-level. In fact at
> the minute I need to use two separate languages for those two requirements
> (or three if you count inline assembly as a separate language).
>

well, I guess in my case is partly shown by behavioral evidence:
much of the code is C;
some is ASM;
some is BGBScript.

I have some C++ as well, but apparently a bit more C++ code than I have
BGBScript code at the moment, but not really by a huge margain (since
both are fairly small). some Java is in use but presently less than that
of BGBScript code.


it would be harder to stat the total amount of ASM, as most of the ASM
resides in C strings, which are then fed into an assembler.

in general, generating ASM in-program inline is actually less painful
than dealing with separate ASM modules, given in the latter case they
need special treatment in the Makefiles, and nicer than inline ASM due
to having a consistent syntax between compilers (and also not forcing me
to deal with the relative horror that is GCC's inline GAS syntax).

not that Intel syntax being "printed" via a printf-style interface is
necessarily much better though, sadly...

>> Well, if you're a programmer it is,
>> which you've led most you converse with to believe that you are ...
>
> I don't think he has stated that in so many words, but he has said:
>
> " I have written a few interpreters ..."
>
> Apparently, he wants to go to the next step towards creating a compiler,
> but
> is coming up with a large number of excuses why he can't; for example he
> goes on to say:
>
> " ... and I thought about winging it but I
> realize there is a science to compiling and there are right and wrong ways
> to do things. I would like to do things the right way but maybe with my
> weak background and broken undergrad CS degree that is expecting too much."
>
> Then there is getting exactly the right textbooks, choosing exactly the
> right language to compile, just the right implementation language, etc.
> (See the thread on comp.compilers from 17.Apr.2012.)
>

yeah.
I know someone like this as well.
lots of talking, lots of questing for the "perfect" tools, ..., never
actually doing much: shoving forwards, writing code, making things work, ...

though, sometimes I get into a rut, but usually it is more because "I
have no idea how I will approach this problem" rather than much to do
with tools per-se.

> Many of us don't understand this, but perhaps, working exclusively in the
> corporate IBM world for so long, where a 'compiler' is a huge, intimidating
> piece of software (and perhaps a 'computer' is still a huge,
> intimidating and *expensive* array of cabinets in an air-conditioned
> room), and where everything has to be done by the book, perhaps it can
> be seen as a big undertaking.
>

it is possible...

I recently argued with someone who honestly believed that the waterfall
method was essentially the one-true-way to develop software.

I disagree, as I generally don't think waterfall is a very effective
strategy in general.


meanwhile, on a different note, people elsewhere were talking about this:
http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf

which describes how Valve goes about things...


or such...

[Nomen Nescio]

"BartC" <b...@freeuk.com> wrote:

> Apparently, he wants to go to the next step towards creating a compiler, but
> is coming up with a large number of excuses why he can't; for example he
> goes on to say:

Well no, I wanted recommendations on a book and then everybody started
telling me what languages to use, what OS, and what tools. The rest of the
time was spent trying to be polite responding to everybody's off-topic
answers. Looking back that was a bad idea.

Hey Bart, I would suggest getting a life instead of trying to psychoanalyze
me. But you can spend your free time however you want.

>
> " ... and I thought about winging it but I
> realize there is a science to compiling and there are right and wrong ways
> to do things. I would like to do things the right way but maybe with my
> weak background and broken undergrad CS degree that is expecting too
> much."

That was in response to John's repeated comments about any undergrad CS
degree that doesn't teach compilers is broken. Do you silly jerkoffs have to
keep quoting out of context or are just incapable of reading a whole thread?

> Then there is getting exactly the right textbooks, choosing exactly the
> right language to compile, just the right implementation language, etc. (See
> the thread on comp.compilers from 17.Apr.2012.)

That was just noise added by people who decided to make up their own
questions. I said a few times I already had a few ideas which books to use
after filtering through the posts. The implementation language would be
assembler. I believe I said that enough times also.

> Many of us don't understand this, but perhaps, working exclusively in the
> corporate IBM world for so long, where a 'compiler' is a huge, intimidating
> piece of software (and perhaps a 'computer' is still a huge, intimidating
> and *expensive* array of cabinets in an air-conditioned room), and where
> everything has to be done by the book, perhaps it can be seen as a big
> undertaking.

Aside from the needless (and sort of sad) attempt at psychoanalysis, and the
unappreciated condescension that is actually a reasonable understanding.
I haven't ever seen shitty software put out by IBM and the compiler logic
manuals from the old days are pretty scary. If all that is necessary than it
is beyond me. Sue me if wanting to do things the right way bothers you. And
by the way, there are few assemblers and few compilers as good as what IBM
wrote, and they pioneered most of the compiler technology. So I don't think
quoting 'compiler' is necessary but I'm "sure" you had "your" reasons. Have
a little common decency and don't be a prick. If that isn't too much to
ask...

The messages will post out of order so by the time you get this you may or
may not have seen the one where I thanked you for the encouragement.
Apparently I was a little too hasty because your latest post was
unnecessary.

[Nomen Nescio]

BGB <cr8...@hotmail.com> wrote:

> On 5/8/2012 8:31 AM, Rugxulo wrote:
> > Hi,
> >
> > On May 8, 12:06 am, Fritz Wuehler
> > <fr...@spamexpire-201205.rodent.frell.theremailer.net> wrote:
> >> "BartC"<b...@freeuk.com> wrote:
> >>> "Fritz Wuehler"<fr...@spamexpire-201205.rodent.frell.theremailer.net> wrote
> >>> in message
> >>> news:2eb99c87e6217fe3...@msgid.frell.theremailer.net...
> >>
> >> It's not bloated at all. Intel's manual set now just counting the basic set
> >> without optimization etc. is about 4100 pages.
> >
> > Presumably most of that is detailed explanations of all the system-
> > level stuff. The x86 instruction set isn't that complex, esp. if you
> > ignore the SIMD stuff.
> >
>
> most of it is because I think they describe instructions like:
> first page, has the instruction forms;
> subsequent pages, basic information about the instruction.

The format could be improved but it's not only the format. AMD seems to do a
better job describing the same architecture.

> if it takes 3 pages of mostly whitespace to describe a single
> instruction, it follows that there will be a lot more pages...

That is not the reason, the reason is arbitrary complexity. Intel's designs
are convoluted piles of doggy doo. Other processor manuals can be shorter
not because they do less but they do it with more clarity and purpose.
Intel's manuals betray the fact they just added whatever Microsoft asked for
so they could write more multimedia apps than the other guys.

> if compactness were more of a concern, they would probably put all of
> the information about an instruction on a single page, or hell, even
> list off multiple instructions in a single table.

Compactness isn't a concern but just like a 300 page language spec tells you
alot about that language vs. a language with a 50 page spec, the complexity
and probably a bad design are exposed by needing so many pages to explain it to
where people can actually use it to some degree.

> > He's basically saying the truth, though, you don't need anything more
> > than simple file I/O to write a compiler, e.g. the original Pascal
> > compiled itself.

Yeah but to get to that point you have to target an actual machine or VM, so
there is quite alot of knowledge required of the OS and machine to be able
to do code generation, register allocation, etc. Maybe I missed his
point. If he was saying you don't need much of an OS to *produce* a compiler
than ok. If he was saying you don't need to know anything about the OS or
architecture to write a compiler that is worth anything then I have no idea
why he is saying that unless he is thinking C language on a POSIX UNIX/libc
platform where you are insolated from reality and don't have to know
anything but C and library calls. Then you just let the C compiler and the
rest of the toolchain work. What I am thinking about is a compiler that
generates object code or at least assembler for a specific target, so you
have to know quite a bit about the target or you can obviously never write
it. I lost the context of this point now, and I don't want to argue so..it
is what it is.

> > I doubt Intel is to blame for UNIX (tm). ;-)

I'm responding to you in a separate post but they often arrive out of order
or not at all so...

Intel is to blame for almost everything and surely everything that runs on
Intel has to do things at some level according to Intel's abominations. Look
around and you'll find quite a few instances of this.

> > And believe it or not, there isn't that much legacy in *nix,

Yes there is, from the idiotic command names and messages ("I'm a stand up
comedian for my day job") to the way they do many other things. They don't
know how to change for the better without carrying legacy limitaions. IBM
has been great at making progress, still having the old stuff work, but
allowing new stuff to work the best way possible without legacy
baggage. UNIX continues to live with idiotic, broken designs just because
everybody accepts it. Commercial UNIX has a long long way to go to become a
professional OS that does everything enterprises need and doesn't produce
embarassing oops or sorry messages. It's total childish horseshit at this
point. It also says alot about the personality of the guys who wrote it.

> > or at least Linux doesn't follow it so closely that it refuses everything else.

That doesn't really matter, Linux is still clumsy and broken and refuses to
learn from other non-UNIX OS that do things alot better.

> Linux is a lot more prone to be like "whatever, now your old code is
> broken...", so occasionally code intended for older versions of Linux
> needs to be ported to newer versions.

That is more about the apps and their thousands of layers than actual stuff
in Linux. HAL, dbus, they keep shooting themselves in the head and don't
have the common decency to die. They never admit they have no clue what
they're doing. They just try stuff and if it seems to work they claim it's
the future. Then two releases later it is the past.

> the CPU itself can run 64, 32, and 16 bit code all at the same time.

But no OS supports that as far as I know. In IBM you can run 24, 31, and 64
bit code in *one* program. Elf is a big part of the problem, it has no
provisions for dealing with this. IBM doesn't use that so.. no UNIX, no problem.

> I am not really sure what is going on in Linux land, more likely they
> just didn't bother supporting both modes at the same time.

If you have two sets of glibc and some other stuff and the kernel enablement
you can run 32 or 64 bit apps. But on IBM you don't need libraries to be in
a specific mode, everything can call everything else.

> X32 is nifty mostly in that it allows 32 bit code to exist without
> needing mode changing, and the compiler can be (probably) smart enough
> to glue around some other issues.

I will have to read up on this but the question remains why did it take so
long? This is an example of how Intel has its collective head up its ass and
never does things right day one. IBM does.

> more generally, it would allow more easily using extended registers and
> 64-bit integer math from 32-bit code. however, it is, technically, still
> a bit of a hack.

The assemblers all choke on this now. They will have to be fixed.

> I suspect most of the issues are probably mostly due to how the
> compilers and ABIs traditionally work, rather than being the fault of
> the CPU architecture per-se.

Well it is the fault of the CPU architecture per se because Intel didn't
give the OS and compiler designers good ways to accomplish these things from
the beginning. It shows there was no planning and no understanding of
anything. Now after it goes live and everybody says hey this sucks then they
say ok we will add on another thousand pages to our manual and 400 more
instructions so you can have what you should have had 20 years ago.

>
> otherwise, the ABI would need something like having it be up to the
> loader to determine things like structure layout (sort of like in the
> JVM, where the VM itself manages things like physical class layout, ...).

This problem was solved in the 1980s by other people. UNIX and Intel *just
don't get it*

> > "I'm sure Coco is just as much impossible to use on z/OS as
> > yacc or lex."
> >
> > Well, the real problem is trying to bootstrap with a suitable language
> > and compiler, even if that is something you don't want to use full-
> > time. I guess that's your call, though, but most things indeed do
> > assume C or similar. I guess you can hand-translate stuff or just
> > rewrite from scratch once you understand it (which sounds like your
> > goal).

That isn't a big deal, the only thing is you guys need to realize there
isn't anything available to do that on z/OS for new languages. The way to do
it is to write it in assembler or PL/I or C and then bootstrap it there.

[Nomen Nescio]

>> The latest Z Principles Of Operation is 1300 pages. z/OS has way more
>> hardware capability than Intel and the doc is 25% of the size. Another
>> difference with z/OS is they actually write good doc. Linux has basically
>> no doc except what people feel like writing. Windows has a lot of doc but
>> Windows doesn't do 10% of what z/OS does.

> Which Linux? There are a billion incompatible distros. And Windows has so
> many competing technologies too (Java, C#, HTML5+JS, C++), not counting
> other deprecated stuff. It can definitely be confusing if you let it.

But the issue was on documentation. None of them have much except for the
Red Hat distros and even they are cutting down a lot. And most of what there
is is user stuff like how to use the desktop. They stopped documenting the
compilers independently of gcc. Everything is whatever they give you,
sometimes something, sometimes nothing. It hasn't anything to do with what
distro, it's an issue of Linux being a community pile.

> > > If it is compilers you're trying to work on, they are one of those
> > > applications that are largely independent of OS, of user interfaces or
> > > graphics, of almost anything. They have an input file, and an output
> > > file. So you don't need to build on any 'crap' apart from file input
> > > and output, and even then you can sometimes make do with console i/o
> > > instead.
>
> > I'm not sure how that can be since the code generation has to be for a
> > specific target and optimization is heavily target-based.

> He's basically saying the truth, though, you don't need anything more than
> simple file I/O to write a compiler, e.g. the original Pascal compiled
> itself.

My question was how can a compiler be OS independent when every OS or OS
family has different interfaces and every platform has a different ISA? You
have to code to something. The only way the OS wouldn't matter is if you
were targeting some universally available VM.

You seem to be talking about what OS facilities you need to write the
compiler. But once you write it it has to actually generate code and have a
runtime or it won't do much.

> Well, the real problem is trying to bootstrap with a suitable language and
> compiler, even if that is something you don't want to use full- time.

I expect I would have to do the traditional write the code in assembler and
bootstrap and go from there approach.

> I guess that's your call, though, but most things indeed do assume C or
> similar. I guess you can hand-translate stuff or just rewrite from scratch
> once you understand it (which sounds like your goal).

My question was on books that might be good. I received a few good
suggestions and I can work from those, they are written for a similar
environment.

Stop posting through gogooele groups!

[BartC]

"Nomen Nescio" <nob...@dizum.com> wrote in message
news:c6f63721e0eaf403...@dizum.com...

> "BartC" <b...@freeuk.com> wrote:

> Hey Bart, I would suggest getting a life instead of trying to
> psychoanalyze
> me. But you can spend your free time however you want.

Are you and Fritz the same person? If not then I'm confused..

--
Bartc

[BGB]

same here, usless multiple names are being used, then this name was not
seen either here or on the original thread in comp.compilers prior to
this point.

[Nomen Nescio]

BGB <cr8...@hotmail.com> wrote:

> On 5/7/2012 9:41 AM, Fritz Wuehler wrote:
> > On Sun May 6 06:06:13 2012 cr8...@hotmail.com wrote:
> >
> >> whether or not a person "likes" C doesn't really matter all that much,
> >> given it (and other more-or-less related languages) are so common as to be
> >> largely inescapable.
> >
> > That is only true in the UNIX and PC world. In my work I have never had to
> > use C and it probably is only used for less than 1% of the work that people
> > in my business do. Otherwise I am sure I would use it. But you would be
> > surprised how many years I have been working as a developer and never used it.
> >
>
> well, to some extent it is also on Mobile devices (phones, ...) but
> competes there with Java and C# depending on the particular phone
> (iPhone is mostly Objective-C, Android mostly Java, and Windows Phone
> mostly C# and XNA and similar...).

Java seems to have won the phone wars. I don't know of any C phone
platform. Even Symbian is C++.

> I am primarily a PC developer though (Windows and Linux), and would
> consider OSX if it were not so absurdly expensive.

Why OSX? If you want a good BSD there are a few notably Open and Free, both
are open source and free as in free. I think you could get a good reputation
joining one of those projects as a developer, especially OpenBSD.

> well, I aim to try to make reasonably good and solid code, but from a
> design POV, things tend to be mostly mediocre, but as I see it mediocre
> is a fairly good place to be.

That is the engineer in you talking

> the language design is arguably less elegant, but partly because the
> language wasn't aiming to be "simple" or "elegant", but rather to try to
> look and act more like traditional "industrial strength" languages.

I think it would help for you to look beyond the state of the PC art and get
a look at what industrial strength stuff we have in the mainframe world.
There is no comparison and you can learn alot. Unfortunately getting a
system to work on is not a simple matter.

> but, otherwise, if a person were to present a language looking like a
> hybrid of Scheme and Self, almost no one would willingly use it (this is
> closer to what I started out with, many years ago...).

But is that really your goal? You seem to enjoy writing projects for
yourself. If so what do you care what other people like? And if to sell you
will have to compromise alot. Crap sells, good stuff doesn't go
anymore. You're about 30 years too late. I remember when it did though.

> the main issue is that pretty much the only people with such IBM systems
> are mostly companies and similar. they aren't something a typical
> end-user is going to be using, nor something which the usual developer
> will have much reason to target.

absolutely true

> > If you had a good PL/I or PL/M available *and* the header files then maybe
> > you would like those better. Most people have to choose between C and
> > nothing else, so yeah C looks good then. What else have you seen that can
> > get the same job done?
> >
>
> well, long ago, there was Pascal...

Yes but Pascal as designed was worthless outside the classroom. Borland did
a job on it though!

> a quick look shows PL/I looking like a very verbose language, which
> isn't really my thing.

I guess it depends on what you mean about verbose. If you mean DO and END
instead of {} then yeah it is. I like the syntax of PL/I because it's more
uniform than C syntax. The block structure is symmetric. PL/I has nice
features like the ability to define functions inside other functions and a
lot of control over scoping and allocation, plus a ton of builtins. You
don't have to use all that though. It's as minimal a language as you want
and as full a language as you want.

> partly because changing the world isn't really my goal in life (whether
> the world changes or stays the same doesn't really seem to be a big
> issue).

I don't have a goal of changing the world either but I do believe in doing
the best I can at whatever I do and that indirectly that changes things for
the better. Maybe because I am older than you and I remember when people
cared more about things and the world was in better shape. Now that
everybody is for himself and doesn't care about anything it's not very nice
living in that situation.

> similarly, I don't really consider "human nature" to really be "a bad
> thing to be fought against", but rather yet another cost/benefit
> tradeoff, to be weighted along with many more-strictly-technical
> tradeoffs.

That's not what I meant. I meant your comment was an observation on human
nature, not code. Anyway your pragmatism means you probably have an easier
time with things. Idealism is hard to live up to.

> so, it is a world where nearly everything is cost/benefit tradeoffs,
> ranging from technical concerns, to the behaviors of all the people
> involved, to the various popular opinions and expectations, ...

Good engineering view.

> well, in one sense, one does get "the most bang for the buck" by
> pursuing mediocrity.

Why stop there? You could put out the worst crap possible that still doesn't
get you fired...

> it would be like a musician choosing to mostly make gangsta rap as "this
> is where the money is", and game-developers making a lot of FPS and
> sports-themed games (as opposed to the once-popular RTS and RPG games),
> ...

Which is why I work for companies who know what products they want. If I
wrote what I wanted to write I would sell 10 copies.

> > Thanks for your posts BGB always enjoyable.
> >
>
> fair enough, but given the often lacking responses or commentary, I tend
> to think that few people actually care all that much.

I look at your posts more of a zen of coding stream of consciousness blog.
I don't get alot of what you write about but I find it interesting anyway. I
figure it's part of your process. I don't share much about my work because
the lawyers are always breathing down our necks with their NDAs so I like to
hear what other people are doing and thinking in tech even if most of it has
no connection to me.

[BartC]

"Nomen Nescio" <nob...@dizum.com> wrote in message

news:9c906645e1e5990f...@dizum.com...

> BGB <cr8...@hotmail.com> wrote:
>> On 5/8/2012 8:31 AM, Rugxulo wrote:

>> > He's basically saying the truth, though, you don't need anything more
>> > than simple file I/O to write a compiler, e.g. the original Pascal
>> > compiled itself.
>
> Yeah but to get to that point you have to target an actual machine or VM,
> so
> there is quite alot of knowledge required of the OS and machine to be able
> to do code generation, register allocation, etc. Maybe I missed his
> point. If he was saying you don't need much of an OS to *produce* a
> compiler
> than ok.

My comment was in response to Fritz's about building on broken code. None of
that broken code really stops you either producing a compiler, or getting it
to generate decent code for the architecture you're targeting. In fact I
believe some people have already done it.

If the complaint was about having to generate code for a flawed
architecture, then that's too bad! Probably all compiler writers have cursed
designers of chips and instruction sets at some point.

> If he was saying you don't need to know anything about the OS or
> architecture

You need to know the architecture. Unless you are targeting an intermediate
language; then that language can take care of some things.

> to write a compiler that is worth anything

A compiler lets you write code in a particular language. If it does that job
reasonably well, then it works.

> then I have no idea
> why he is saying that unless he is thinking C language on a POSIX
> UNIX/libc
> platform where you are insolated from reality

My first compilers were for machines without an operating system. (In fact
without any software at all, except what I managed to get into them using
my own languages and tools. When you start off with bare microprocessors,
then you tend to become self-sufficient.)

I don't know if that counts as 'reality'.

--
Bartc

[Nomen Nescio]

It's anonymous remailers, whichever one posts the message. Messages arrive
out of order. Sometimes they take days to post sometimes an hour or two
sometimes they come all at the same time. You cannot tell anything about
when they were sent unless something in what is written in the message tells
you.

[Rod Pemberton]

"Nomen Nescio" <nob...@dizum.com> wrote in message

news:5c9a007581beb227...@dizum.com...
...

> PL/I has nice features like the ability to define functions inside other

> functions [...]

True.

Do you know how many times I've needed that in C? Exactly zero.

Do you know how many times I've wanted that in C? Exactly once.

I still do want it. I want it for implementing threaded interpreters, i.e.,
Forth. In a simple Forth-style indirect threaded interpreter, you'll have
four functions which share a few variables. Most modern C compilers do not
allow "register" keyword on file scope variables. This is to prevent
accidentally allocating a register for the life of the program. I.e., a
register can only be allocated for a variable for local or "auto" scope.
So, the ability to nest functions if available in C *would* allow all
variables to be in scope and use register variables. Since neither the
ability to nest functions nor the ability to have file scope register
variables is available in C (anymore), alternate methods must be found if
you want to register optimize the shared variables. I have an idea in mind,
but it'll be some time before I intentionally fubar my interpreter to see if
it works out ...

Officially, the ability to nest functions falls under multiple-entry points,
similar to Duff's device being used in C to allow multiple-entry points for
co-routines. C allows multiple exit points. C also allows unstructured
programming. However, with structured programming, you don't need
multiple-entry or multiple-exit points. Structured programming is
single-entry and single-exit.


Rod Pemberton

[Rod Pemberton]

"Nomen Nescio" <nob...@dizum.com> wrote in message

news:3b0a8694de2d4937...@dizum.com...
...

> My question was how can a compiler be OS independent when every OS or OS
> family has different interfaces and every platform has a different ISA?

The word you're looking for is "mostly" to preface "OS independent."

It's based on the idea that some things are standardized across computing
platforms. You're going to have integer addition, subtraction, division,
multiplication, logical or, logical xor, logical and. You're also going to
be able to implement control-flow: loops, jumps, case statements, etc.

Once you've implemented something really simple, you expand and rewrite
from there. Eventually, you'll have a powerful compiler, or you'll be able
to
bootstrap an existing one.

> You have to code to something.

Yes.

> The only way the OS wouldn't matter is if you
> were targeting some universally available VM.

True.


Rod Pemberton

[Rod Pemberton]

"Nomen Nescio" <nob...@dizum.com> wrote in message

news:c6f63721e0eaf403...@dizum.com...
...

> Aside from the needless (and sort of sad) attempt at psychoanalysis, and
> the unappreciated condescension that is actually a reasonable
understanding.

Is this your way of asking for help?

I don't remember too much PL/I, but I'm sure a few do. They could help, if
you decide to use PL/I. Or, I could be "refreshed" in PL/I. But, ISTM,
that you have the basic background needed to code a compiler. As BartC
quoted from comp.compilers:

"I have written a few interpreters ... "

So, instead of executing the code, you emit code. It's not quite that
simple, but it's very similar. You need to not emit what would execute, but
emit just the source as a program. It's a trivial but important difference.
An interpreter can do that. So can a compiler.


Rod Pemberton

[Nomen Nescio]

Rod, your attitude is getting old. Please don't make me killfile you. You're
taking stuff out of context and making bizarre comments on things you don't
understand and then accusing me of conclusions you came up with based on
your misunderstandings of what I never said or meant. It's starting to look
clinical with you bud.

> > Aside from that as I said, C is too high level to do what I do and too
> > low level for anything else on the machines I work on.
>
> Lol! That's a complete contradiction!

No. Again:

The OS and services are written in assembler and PL/X (a high level
assembler). They require direct register manipulation and use of
interfaces not available in any language other than assembler or PL/X. There
is a new way in the latest copies of their Metal C compiler to write
assembler in C. That is the only way you can do this. But then your program
is 95% assembler so if you want to call it C you're just lying to
yourself. You probably wouldn't mind that though.

We've been over this many times. You haven't looked at it, you don't
understand what you're talking about and what's hard to believe is you
continue to argue about it as if you do. Spare me. Spare us all. Your post
is 100% noise.

If you think what I said is "LOL That's a complete contradiction" then tell
me how to do the following from C without using the assembler available in
Metal C, in other words using pure C. For extra points, you can tell me how
you would do it in any other HLL available on IBM from C++ to Java or any
language you choose.

1. Change the ASC mode to AR
2. Set an FRR
3. Reserve a system LX
4. Get the storage key for a block of storage addressed in general register 7
5. Allocate a block of SQA
6. Schedule an SRB

Much more than the above is needed to write systems software but you can't
do any of them in anything but assembler or Metal C's assembler. It's
assembler, not C. I know you still don't get it but there's the
challenge. Prove me wrong. You can't.

> Well, if you're a programmer it is,

I write systems software not applications software. On IBM that means
assembler. C can't cut it. It's too high level for what I do. And it's too
low level for anything else. They write the GUIs in Java or C++ or Rexx. C
doesn't have any reason to live on IBM. No offense, that's just the reality.

> > If you had a good PL/I or PL/M available *and* the header files then
> > maybe you would like those better.
>
> This makes no sense after you bashed C ...

I wasn't talking to you and you're quoting me out of context. BTW it makes
perfect sense if you actually read and understood what was written. You kind
of sound like a C-uberalles bot that scans usenet for posts where people
say "you can't do X in C" and then you generate inappropriate misguided
off-topic out of context rants to steer the conversation back in the
direction where you can say C is great or kill the messenger that said your
emperor has no clothes. People who don't know you could get confused and
then you mess up a perfectly good thread. Rod (or Rod bot, whatever) not
every thread is about C or Intel. Some threads are about mainframes or IBM
or tons of other stuff you don't understand. You could learn or you could
just go to the next thread or you can be an obnoxious pain in the ass.
Unfortunately you choose "C" most of the time because it requires the least
amount of effort.

> > All the header files are in assembler and PL/X (a high level assembler)
> > and it really makes working on this OS enjoyable.
>
> Many of your statements are vague and leading like that one.

No, I gave the manual links. If you wanted to participate in the discussion
you could actually read and learn. You could ask questions instead of making
idiotic false statements. Right now you're just being a pain in the ass for
recreation or as part of your C-uberalles bot script. Either way it's not
very admirable. Don't make me killfile you bud. I will if I have to. You
lost most of your charm with that other assinine post you made and you're
skating now on thin ice.

The point is if you like writing assembler z/OS is a great platform.
Everything is set up for the assembler programmer with a great assembler,
tracing, manuals, interfaces, all the stuff you need to support development
in assembler. And a great simple but powerful and flexible architecture.
I haven't seen any other environment that offers that. Just a minute, I am
going to run a program that runs in mixed 24, 31, and 64 bit mode. There I
just did it. Try that on Intel with your OS of choice. Oh, you can't.

> > But I understand if you write apps you like whatever OS is popular.
>
> I'll give you the benefit of the doubt on that. I'll assume you actually
> meant "code" or "program", not "write" - as in an English paper ... So, you
> do intend to code your Forth, which is an app typically, on a popular OS?
> Congrats! You've progressed, immensely.

No, wrong again. And I wasn't talking to you. And you quoted me out of
context again. Earlier I was starting to think you have some kind of
personality disorder. Now I'm sure of it because of the way you coded that
bot in Javascript. Please try to behave or at least stay on the meds so you
don't embarrass yourself more than you have to. It's not that you have
nothing to say. It's just that the stupid-ass comments and consistent
deliberate misquoting make everybody wonder since you're bullshitting on
this maybe you're bullshitting on everything else you write. Nobody likes a
bullshitter. If they read your posts they'll see the pattern. Clean up your
act bud, it's time.

[thomas...@gmx.at]

On Friday, May 4, 2012 8:08:32 PM UTC+2, (unknown) wrote:
> glen herrmannsfeldt <g...@nospam.ugcs.caltech.edu> wrote:
>
> >> 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.
>
> I gathered that from John's comments as well. Thanks to you both.
>
> >>>> 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.
>
> I have access to pretty much everything at work.

So you have access to z/OS, great.
Can you do me a favor?

I would like to know, if my project (Seed7) can be
ported to z/OS. Once a co-worker with access to z/OS
was successful in compiling many of the source files.
But some minor errors showed also up. Later he got
nervous about the costs (which were charged as CPU-
seconds) and refused to do another try. Now I am in
a different company so this contact is improbable
to work again.

Please, please help me.
To compile Seed7 you need to download the latest version
(currently seed7_05_20120506.tgz) from:

http://sourceforge.net/projects/seed7/files/seed7

How the *.tgz archive is split up into files, is
described here:

http://seed7.sourceforge.net/faq.htm#uncompress

If z/OS cannot do this you could probably unpack
the *.tgz archive on a PC (or Mac, etc.) and copy
the files from the seed7 directory to z/OS. I
assume that z/OS supports sub-directories.

Under z/OS you essentially only need two tools:
Make and a C compiler (I know, you don't like C,
but in this case it is not necessary to program
in C). In the optimal case you just switch to the
seed7/src directory and do:

make depend
make

Probably some warnings and errors will show up:
Can you please send me this warnings and errors.

I would also be interested in the file stdio.h
from z/OS. It is an include file for C, so there
are probably no copyright issues.

Many many thanks in advance for your effort.


Regards,
Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[Nomen Nescio]

"Rod Pemberton" <do_no...@notemailntt.cmm> wrote:

> "Nomen Nescio" <nob...@dizum.com> wrote in message
> news:c6f63721e0eaf403...@dizum.com...
> ...
>
> > Aside from the needless (and sort of sad) attempt at psychoanalysis, and
> > the unappreciated condescension that is actually a reasonable
> understanding.
>
> Is this your way of asking for help?

No, it just means the compilers I have seen are very large and complicated.
That looks like a lot to bite off. I don't have time to get through dozens
of 300 to 1,000+ page books only to find out they suck, which is why I asked
about books. Not about what OS, not about what language, just what books
would be good given the parameters I stated. Have a look at the PLM for IBM
PL/I F. If that doesn't scare the shit out of you then I don't know what
will.

[BartC]

"Nomen Nescio" <nob...@dizum.com> wrote in message

news:901dc575fe053292...@dizum.com...

> assembler in C. That is the only way you can do this. But then your
> program
> is 95% assembler so if you want to call it C you're just lying to
> yourself.

> If you think what I said is "LOL That's a complete contradiction" then
> tell
> me how to do the following from C without using the assembler available in
> Metal C, in other words using pure C. For extra points, you can tell me
> how
> you would do it in any other HLL available on IBM from C++ to Java or any
> language you choose.
>
> 1. Change the ASC mode to AR
> 2. Set an FRR
> 3. Reserve a system LX
> 4. Get the storage key for a block of storage addressed in general
> register 7
> 5. Allocate a block of SQA
> 6. Schedule an SRB

Congratulations - you've just invented a high-level language for writing
systems software in! Now you just need to implement it.

And surely more than 5% of the source code of even a systems program must be
concerned with things such as variable declarations, type declarations,
defining constants, declaring functions/function signatures, comments,
arrays, records, arithmetic expressions, conditional statements, loop
structures, switch/case statements, etc. etc.

These are all things that are admirably suited for any high-level language,
even C.

I don't understand what those specific constructs mean, and perhaps they
need to execute in some delicate, complicated CPU context where you can't
let a normal compiler loose corrupting registers all over the place. But
I'm sure there are better ways of allowing this sort of control from a
high-level language without 95% of it needing to be assembler.

(As it happens, my very first compiler, for a college project, was to
implement a machine-oriented language intended for just this sort of thing,
where the language could directly refer to hardware resources such machine
registers. It worked, and could compile itself, but the language didn't
catch on and the systems software of this (non-IBM) mainframe was still
based on assembler. Probably about fifteen years too late though..)

--
Bartc

[BGB]

I currently implement threaded code by having nearly all of the shared
state being held in a structure I call a "context", which is passed to
each function (along with a structure for the decoded version of the
instruction).


a downside with nested functions though would be the creation of giant
functions, and likely the required use of #include to split them across
multiple functions.

also, several compilers also implement nested functions as an extension,
but they work more as function-scope-limited pseudo-closures and so
would not likely be nearly as useful for implementing threaded code.

[BartC]

"Rod Pemberton" <do_no...@notemailntt.cmm> wrote in message

news:jofrl8$vu7$1...@speranza.aioe.org...

> "Nomen Nescio" <nob...@dizum.com> wrote in message
> news:5c9a007581beb227...@dizum.com...
> ...
>
>> PL/I has nice features like the ability to define functions inside other
>> functions [...]
>
> True.
>
> Do you know how many times I've needed that in C? Exactly zero.
>
> Do you know how many times I've wanted that in C? Exactly once.

There are any number of language features that seem a good idea, but are not
really necessary, and never get used. (And quite a few I've implemented,
then forgot about completely, then was pleasantly surprised when I tried
them and they worked..)

Nested functions I've never had a need to use, and sound a nightmare to
implement (I've always imagined a stack of frame pointers would be needed).

Yet, I have just tried that on the most recent of my languages that actually
works. It said "Nested proc not allowed". OK. Then I wondered what would
happen if I removed that message... and it seemed to work!

However it works by simply defining the name of the nested function, inside
the namespace of the enclosing function. So it can't access locals of the
enclosing function, which makes sense as the nested function can be called
from outside too, when active elements of the enclosing function might not
exist.

I've no idea how PL/I implements them, but it can't be that difficult if I
can do it without even trying (not only without writing any extra code, but
actually taking code out! Although I'm sure there would be a few issues to
deal with when tested properly).

> Officially, the ability to nest functions falls under multiple-entry
> points,
> similar to Duff's device being used in C to allow multiple-entry points
> for
> co-routines.

Now there's one untidy feature of C (unstructured case labels) that I would
deliberately take out even if I was creating a C compiler. It's just too
weird.

--
Bartc

[Nomen Nescio]

"BartC" <b...@freeuk.com> wrote:

> I agree the Intel/AMD docs are now bloated, and that their processors are a
> mess (the better ones never got popular). And the Z manual is surprisingly
> readable (some good ideas to be gleaned from it even if I never get to use
> one).
>
> However, when I had to do some low-level work recently, I worked from an
> instruction set summary on the last five pages of the original 8086
> datasheet. This provided most of what I needed! I hardly ever go near the
> official docs.

You can do that with IBM doc as well since the Principles of Operation from
every generation are still available online. The latest version for
z/Architecture is too much. For learning I always suggest people start with
the S/370 or S/360 version (depnding on who's asking) and get the basics
without seeing all those pages and panicking. I wouldn't wish the latest
copy on anybody.

I agree Intel is horrible. The designs are so convoluted I can't believe
they sell anything except for Windows keeping them alive. I try to read the
AMD docs instead because of Intel's 2001 A Space Oddysey fonts. What is that
all about.

There are a couple of ways to actually write code for a mainframe without
having one. The best way is the Hercules emulator and installing a vintage
OS MVS 3.8. You can get the assembler, PL/I, COBOL, RPG (oh dear God no!),
and some other stuff and run the actual OS and compilers. It's amazing.

The other way is to use the Java based Z390 simulator from Don Higgins. It
doesn't use actual IBM code, Don wrote his own assembler and COBOL that work
very similar to IBM's and it has a self contained environment for testing
stuff. Higgins has been doing this since S/370, he put out a S/370 cross
assembler that ran on MS-DOS. His stuff is way cool, but it falls short
because he cannot legally give you the IBM macro library and without that
you can't do any serious coding. It's good for people to get started who
just want to see what z assembler is like but if you want to run the real
thing Hercules lets you do it. The best thing is how nice the assembler and
architecture are, a pleasure to code on.


> > is not the same as bloated. z/OS is a real OS, it's not a toy for desktops
> > or workgroup servers. Fortune 1000 companies run on a single box.
>
> It's dangerous calling any PC a 'toy'. A Ł200 netbook probably has more
> computing power than any 1970s mainframe.

Yes and no. The clock cycles are certainly faster than a 1970s mainframe,
but as far as how much work they can do, a 1970s mainframe can still beat
any PC. It's a combination of the OS and hardware working together instead
of just tolerating each other. The OS is designed for throughput and whole
companies ran then with tens of thousands of online users on one box and all
their regulatory compliance reports, statements, etc. You don't find any
company that can run their whole operation on one PC. PC is fine for doing
one or two things at a time. After that they just run out of steam. The
mainframe keeps on going.

> I think you said you were familiar with the assembler on your system. Fine,
> then a compiler will translate some source code (perhaps of a language that
> you devise) in a file, to HLASM source code in another file. OS matters
> really hardly come into it, not until you need to work on a runtime anyway,
> but that's separate from creating a compiler.

I looked into this earlier and I was surprised to find out none of the IBM
compilers work this way. They all generate object code directly. There was a
discussion on comp.censorship (whoops I mean comp.compilers) about it. The
only person generating assembler source from his compiler is a guy who
writes a 3rd party C/C++ compiler. All the IBM stuff does it the hard
way. The runtime is obviously a big part of it but yeah I didn't include it
in the actual compiler part because I may be able to avoid runtime
completely by invoking OS services. I have to think about it when I get there.

I wanted to thank you for your posts on comp.censorship for the
encouragement and good ideas. Of course that post didn't get posted either.

[BGB]

On 5/10/2012 8:18 AM, BartC wrote:
>
>
> "Rod Pemberton" <do_no...@notemailntt.cmm> wrote in message
> news:jofrl8$vu7$1...@speranza.aioe.org...
>> "Nomen Nescio" <nob...@dizum.com> wrote in message
>> news:5c9a007581beb227...@dizum.com...
>> ...
>>
>>> PL/I has nice features like the ability to define functions inside other
>>> functions [...]
>>
>> True.
>>
>> Do you know how many times I've needed that in C? Exactly zero.
>>
>> Do you know how many times I've wanted that in C? Exactly once.
>
> There are any number of language features that seem a good idea, but are
> not
> really necessary, and never get used. (And quite a few I've implemented,
> then forgot about completely, then was pleasantly surprised when I tried
> them and they worked..)
>
> Nested functions I've never had a need to use, and sound a nightmare to
> implement (I've always imagined a stack of frame pointers would be needed).
>
> Yet, I have just tried that on the most recent of my languages that
> actually
> works. It said "Nested proc not allowed". OK. Then I wondered what would
> happen if I removed that message... and it seemed to work!
>

in my case, it usually alternates between storing locals/... more
"directly", or storing them in a heap-allocated structure.

so, in the normal case (no closure):
allocates locals in a stack, or in the stack frame (for compiled code);
in the capture-case, uses a heap-allocated form.

my C compiler used a struct-like form, essentially folding all of the
locals into a hidden struct in cases where a closure was created, and
would access the locals indirectly;
in the case of the current BGBScript VM, the strategy is to instead use
lists of cons cells (note that most fixed-type values in the BSVM are
boxed heap-objects, so a list works fine in this case).

a technical disadvantage here is that closures will leak memory, so are
best used sparingly.

worse yet, the present form of the current "import" statement often
leads to full closures being created (since the "import" is implemented
internally using a lexically-scoped variable). this may need to be
resolved somehow.

> However it works by simply defining the name of the nested function, inside
> the namespace of the enclosing function. So it can't access locals of the
> enclosing function, which makes sense as the nested function can be called
> from outside too, when active elements of the enclosing function might
> not exist.
>

I call this the "no capture" case:
even if a nested function is declared, if it never references a variable
outside its own scope, there is no need to capture the environment for
it, and it can be treated as a raw block.

there is presently an ugly hybrid case in the case of "ifdef/ifndef"
though, which may reference the enclosing scope but need not capture it
(these are implemented by folding everything inside the ifdef into its
own block, which may statically evaluate whether or not to call the
block or treat the call as a no-op).

> I've no idea how PL/I implements them, but it can't be that difficult if I
> can do it without even trying (not only without writing any extra code, but
> actually taking code out! Although I'm sure there would be a few issues to
> deal with when tested properly).
>

I have little idea either.

>> Officially, the ability to nest functions falls under multiple-entry
>> points,
>> similar to Duff's device being used in C to allow multiple-entry points
>> for
>> co-routines.
>
> Now there's one untidy feature of C (unstructured case labels) that I would
> deliberately take out even if I was creating a C compiler. It's just too
> weird.
>

I don't think my compiler actually supported it in the first place.
typically, switch was implemented specially, and had just walked the
list of contained statements to find all of the 'case' labels (and put
them in an array).

since it never checked inside of other statements, it would simply
ignore the other case labels, and the other parts of the compiler would
probably complain about seeing a case label in an unexpected place.

despite being a violation of the C standard, I didn't really care that
much, and probably most code wouldn't really notice either.


meanwhile:
I consider whether it would be worthwhile to add logic to move partly
from indirect threaded code (in a loop), to using a function to call a
group of operations-handlers in a fixed sequence ("mini-traces"). the
main complexity here would be in adding logic to classify which
operations are and are not "safe" for such an operation (and determining
the best way to indicate this classification).

this would essentially be little more than a micro-optimization though.

[Kaz Kylheku]

On 2012-05-10, BartC <b...@freeuk.com> wrote:
>
>
> "Rod Pemberton" <do_no...@notemailntt.cmm> wrote in message
> news:jofrl8$vu7$1...@speranza.aioe.org...
>> "Nomen Nescio" <nob...@dizum.com> wrote in message
>> news:5c9a007581beb227...@dizum.com...
>> ...
>>
>>> PL/I has nice features like the ability to define functions inside other
>>> functions [...]
>>
>> True.
>>
>> Do you know how many times I've needed that in C? Exactly zero.
>>
>> Do you know how many times I've wanted that in C? Exactly once.
>
> There are any number of language features that seem a good idea, but are not
> really necessary, and never get used.

That is "blub programmer" talk. "The feature is not in Blub, and so it's just
some weird thing that is not needed. I think in Blub, and everything is
possible in Blub." ( http://www.paulgraham.com/avg.html )

Lexically scoped functions are incredibly useful. Even if, when they are passed
as arguments, they are supported in the downward direction only ("downward
funargs") like they are in GNU C and even Pascal (the original Wirth one).

Even if you don't use local functions directly, they are useful in
writing macros. Macro expansions can insert local functions which are then
used by other parts of the macro expansion.

For instance, suppose we have some module which provides a functional
callback interface for enumerating some objects. You pass in a callback
and the callback is invoked for each item in turn.

With local functions, we can direct that callback into the calling
scope instead of making some clumsy function outside of our function,
and put all our context into a clumsy context object.

With some macro syntactic sugar, we can hide that local function and turn that
callback into what appears to be a language construct: for each object, bind
that object to this variable and execute this block of code.

> However it works by simply defining the name of the nested function, inside
> the namespace of the enclosing function. So it can't access locals of the
> enclosing function, which makes sense as the nested function can be called
> from outside too, when active elements of the enclosing function might not
> exist.

No access to the surrounding function's environment means you do not have
true nested functions! You're just playing a simple game with identifer
scope.

Merely scoping the identifier inside the function is not significantly
different from C's file scope functions with internal linkage ("static
functions") and in some ways less useful.

The functions are independent of the local environment, and yet they cannot be
reached from outside the function, either.

[Fritz Wuehler]

[BartC]

"Kaz Kylheku" <k...@kylheku.com> wrote in message
news:201205101...@kylheku.com...

> On 2012-05-10, BartC <b...@freeuk.com> wrote:

[Lexically nested functions]

>> However it works by simply defining the name of the nested function,
>> inside
>> the namespace of the enclosing function. So it can't access locals of the
>> enclosing function, which makes sense as the nested function can be
>> called
>> from outside too, when active elements of the enclosing function might
>> not
>> exist.
>
> No access to the surrounding function's environment means you do not have
> true nested functions! You're just playing a simple game with identifer
> scope.

That's fine. It can still be useful, in being able to define privately named
functions that won't clash with any others, and providing some degree of
encapsulation.

Accessing auto variables of the enclosing function would anyway be akin to
using globals, supposed to be a bad thing. (As I've implemented it, bearing
in mind this was almost by accident, access to more static names *is*
possible without too much trouble.)

> Merely scoping the identifier inside the function is not significantly
> different from C's file scope functions with internal linkage ("static
> functions") and in some ways less useful.

Surely most languages do the same. Proper, arbitrarily nested functions
aren't possible in C (although I suspect you will give a counter-example
using some insane combination of function pointers and macros..).

> The functions are independent of the local environment, and yet they
> cannot be
> reached from outside the function, either.

I allow mine to be accessed from outside, because I haven't implemented the
'private' attribute for such functions.

--
Bartc

[Rod Pemberton]

"Nomen Nescio" <nob...@dizum.com> wrote in message

news:901dc575fe053292...@dizum.com...

> You're taking stuff out of context and making bizarre comments
> on things you don't understand and then accusing me of conclusions
> you came up with based on your misunderstandings of what I never
> said or meant.

Yeah, like thinking someone paranoid enough to use a remailer might also be
old enough to still post to a listserv without anonymizing his name or
email, and like thinking someone as pro-IBM as you might also be someone who
posts to bit.listserv.ibm-main ... Good guess?

> The OS and services are written in assembler and PL/X (a high level
> assembler). They require direct register manipulation and use of
> interfaces not available in any language other than assembler or PL/X.
> There is a new way in the latest copies of their Metal C compiler to
> write assembler in C. That is the only way you can do this. But then
> your program is 95% assembler so if you want to call it C you're just
> lying to yourself. You probably wouldn't mind that though.
>

So, your choices are "assembler and PL/X", but you criticize
"assembler in C" ...

PL/S and PL/X are so obscure, there isn't even an example of them here:
http://www.99-bottles-of-beer.net/

There is a PL/I and PL360 example. Wikipedia doesn't have examples of PL/X
either. So, please, put up a PL/X version so non-IBMers know what it is.

In my search for a PL/X example, I ran across this:

"[PL/X] is an IBM proprietary language so I can't say too much :-) The
language is an abstraction of IBM zArchitecture. It is best described as a
cross between C and assembly. The language is extremely powerful because
assembly can be in-lined when straight PL/X does not suffice."
http://pages.cs.wisc.edu/~tobler/cs/compsci_info.htm

So, now that I know PL/X is basically "PL/I+assembly", I know you're just
"yanking my chain" asswipe ... In essence, the combination is no better
than "C+inline assembly".

I also ran across this:

"PL/X (earlier called PL/S) was an internal IBM language for programming of
basic software, on a slightly higher level than C, but much better.
Unfortunately, it was one of the best guarded company secrets ('so that
competitors would not copy our operating system'). If IBM dared to release
it then, the world would now use PL/X instead of C."
http://www.romanredz.se/cv.htm

And this:

"PL/X as a language was extremely PL/1 like (funny that) but included many
built in functions that were borrowed directly from assembler."

Do you recognize any of these?
http://groups.google.com/group/bit.listserv.ibm-main/msg/9bd9dc22db1f0d6a
http://groups.google.com/group/bit.listserv.ibm-main/msg/04ae13a68acdbc43


And, all that stuff you claimed in other newsgroups about C not running on
z/OS is apparently total bullshit too. It seems three are a bunch of C
compilers available for IBM: SPC, SystemC, Metal C, GCC ...

> We've been over this many times. You haven't looked at it, you don't
> understand what you're talking about and what's hard to believe is you
> continue to argue about it as if you do. Spare me. Spare us all. Your post
> is 100% noise.

No one else you're asking has any experiene with z/OS either! You've *NOT*
been posting in IBM groups. Of the people to whom you're asking questions,
you're the *only* one with IBM experience. And, you knew that prior to
asking us. So, "your post is 100% noise" too ...

FYI, these are IBM groups:

comp.lang.pl1
comp.sys.ibm.as400.misc
comp.databases.ibm-db2
ibm.networking.*
ibm.servers.*

See Midrange.com for IBM mailings
http://www.midrange.com/lists.htm

See gmane.com for archives of mailing lists available via http or nntp:
http://gmane.org/

See Google Groups for IBM listerv email-lists, e.g., bit.listserv.ibm-main
http://groups.google.com/group/bit.listserv.ibm-main/topics?lnk

There haven't been many IBM programmers posting to Usenet in the many years
that I've read, or few years that I've posted. But, I don't read IBM
related groups. There were a few that posted to c.l.a.x., but I think
they've all passed away by now ... You're not going to get IBM specific
details in the groups you're posting to. c.l.a.x. is for x86 assembly.
c.l.f. is for Forth. comp.compilers is for compilers and linkers. c.l.m
(here) is for language syntax.

> If you think what I said is "LOL That's a complete contradiction" then
> tell me how to do the following from C without using the assembler
> available in Metal C, in other words using pure C. For extra points, you
> can tell me how you would do it in any other HLL available on IBM from
> C++ to Java or any language you choose.
>
> 1. Change the ASC mode to AR
> 2. Set an FRR
> 3. Reserve a system LX
> 4. Get the storage key for a block of storage addressed in general
> register 7
> 5. Allocate a block of SQA
> 6. Schedule an SRB
>
> Much more than the above is needed to write systems software but you can't
> do any of them in anything but assembler or Metal C's assembler. It's
> assembler, not C. I know you still don't get it but there's the
> challenge. Prove me wrong. You can't.
>

You're most likely on your own because you fall back on wanting IBM related
details, but aren't posting to dedicated IBM related newsgroups.

So, no I can't prove you wrong, I can only restate what I stated elsewhere
to you (twice now). You consistently *ask* questions about writing a
simple, general purpose compiler from scratch (c.l.a.x. and comp.compilers),
or an interpreter (c.l.f). But, when someone tells you: "It's simple. Start
with basic stuff. Build up from there." You reject that and say: "Oh, I
can't do that because of some z/OS complexity. You don't know what you're
talking about. Here is a massive volume of z/OS manuals to read."
Bullshit! You can do that. If you need some complexity, add it in too. If
whatever you have in mind can only be done from PL/X, then it has to be done
in PL/X. It's as if you're wanting to come across a z/OS programming "god"
who will say: "Oh, if you want to do that, you just need to do this.
Simple." Go back to bit.listserv.ibm-main ...

> I write systems software not applications software. On IBM that means
> assembler. C can't cut it. It's too high level for what I do. And it's too
> low level for anything else. They write the GUIs in Java or C++ or Rexx. C
> doesn't have any reason to live on IBM. No offense, that's just the
> reality.

Yet, you've recently stated you're planning or intend to code applications
software, e.g., Forth interpreter. What do you intend to code it in? (How
many times have I asked that? 3? 5?) Forth is typically coded in assembly
or C. From what you've said, your choice is assembler or PL/X. (How many
times have I stated that? 2?) Forth can be setup as an OS, but, according
to you, that'd be too complicated since there is some sort of mostly
undocumented OS layer that even high-level languages don't have full access
too.

> > > If you had a good PL/I or PL/M available *and* the header files then
> > > maybe you would like those better.
> >
> > This makes no sense after you bashed C ...
>
> I wasn't talking to you and you're quoting me out of context. BTW it makes
> perfect sense if you actually read and understood what was written. You
> kind of sound like a C-uberalles bot that scans usenet for posts where

> people say "you can't do X in C" [...]

Unfortunately, whether you've seen a recent post by me or any post at all,
I've been in the programming and programming language related groups you're
now posting to for some years, e.g., I've never posted to comp.compilers but
have conversed with John Levine and read the group, sometimes. So, yes, I
can understand that you'd think you're "being followed" from group-to-group
by me to promote C, but that's not the case. That's just paranoia.

> [...] and then you generate inappropriate misguided off-topic out of

> context rants to steer the conversation back in the direction where
> you can say C is great or kill the messenger that said your emperor
> has no clothes.

It's from a former PL/I programmer ... Me! Dude, weren't you listening?

And yet, what I've said to you here - on things "on-topic" by your
definition - was also said by others here. And yet, what I've said to you
here - on things "on-topic" by your definition - was said to you by me in
other newsgroups. You've asked the same questions, repeatedly. You've got
the same answers, repeatedly. What's wrong with the answers you've been
given? Do you seriously think I waste time writing garbage? I don't. I
write the truth. I share my experiences. No matter how insane or off-topic
or irrational my posts are to you, they are 100% serious to me.

> Unfortunately you choose "C" most of the time because it requires the
> least amount of effort.

Oh come now, we've been over this. I've programmed in well over a dozen
languages. As I've stated previously, IMO, the only language anywhere near
as powerful as C, is PL/I. Remember, I coded on a 5MLoc application in PL/I
for many years. Admittedly, it wasn't IBM PL/I. It was a variant based on
an earlier standard, but standardized PL/I nonetheless. IIRC, you then went
on a praise PL/I's design and on an IBM z/OS superiority rant. However,
PL/I is neither widespread, nor common. If PL/I or PL/X or assembler is
what you've got to work with, then that's it. Choice made. Stop asking.

> Don't make me killfile you bud.

As I already told you, go ahead. You're not offering me anything, so far.
Whether you get it or not, I've been trying to help you. Don't forget, I
generously and exceptionally openly, provided you a list of numerous topics
that you could converse with me on an alt.* group. After politely doing so,
all I'm getting from you is: "You keep saying C is great, but it isn't ..."
Well, like it or not, it is. It's popularity, ubiquitousness, power,
flexibility, are all proof of that. PL/I is as powerful, but isn't
ubiquitous. Forth is ubiquitous, but isn't popular. Forth isn't as
powerful (IMO). From personal experience, the rest suck. If you don't
believe me, go through and look at the programs on the "99 Bottles of Beer"
website one-by-one.


Rod Pemberton

[Marco van de Voort]

On 2012-05-10, Nomen Nescio <nob...@dizum.com> wrote:
>> I think you said you were familiar with the assembler on your system. Fine,
>> then a compiler will translate some source code (perhaps of a language that
>> you devise) in a file, to HLASM source code in another file. OS matters
>> really hardly come into it, not until you need to work on a runtime anyway,
>> but that's separate from creating a compiler.
>
> I looked into this earlier and I was surprised to find out none of the IBM
> compilers work this way. They all generate object code directly. There was a
> discussion on comp.censorship (whoops I mean comp.compilers) about it. The
> only person generating assembler source from his compiler is a guy who
> writes a 3rd party C/C++ compiler.

Some, like freepascal can do both. Directly objectcode for the popular
targets, and GAS for the rest.

Direct writing is a factor 2 speedier. (and that is an overall factor over
everything parsing-compiling-assembling and linking!)

[Marco van de Voort]

On 2012-05-09, Nomen Nescio <nob...@dizum.com> wrote:
>> (actually I think C headers are a pretty crappy way of describing an API,
>> since C headers in general are not machine translatable to something else.
>> Only certain (macroless and annotated) subset of C are)
>
> I don't mind the C headers so much in principle after all they can write
> their OS however they want. Excessive typedefs do make it very difficult to
> follow when all you want to do is understand what they actually mean, as you
> said. You can't translate all that without a C compiler.

The point was more that even C compiler(+preprocessor) can't expand macros
(#defines) and delete them, since the code can also use macros.

Which in turns means there is no complete header - implementation separation
where you could take the (C) header as an abstract description of an API.

>I realize there are some copies of syscalls and libc calls translated to
> assembler headers but that doesn't always help either because no two Intel
> assmblers are alike and many have no support for structures and then even
> if they do C has its own alignment rules. And those translations aren't
> official so if they're wrong, oh well. It's an ugly pain in the ass.

The code is all less important. I just want to call functions with their
proper types from other languages.

[Fritz Wuehler]

"Rod Pemberton" <do_no...@notemailntt.cmm> wrote:

snip forever

Rod, you definitely have problems buddy and you're off your meds again.
Sorry but it's just not worth filtering through your bizarre off-topic
thread hijacking rants and endless lack of reading comprehension to get
maybe one possible tidbit of interesting factoid. You can't remember
anything beyond one post and even within one post you usually have big
problems. Sad.

I've already shot down all your best attempts at outsmarting me and you were
never able to substantiate anything except your total willingness to argue
about stuff you have no clue about. You're a true Cliff Claven! That last
post of yours is a combination of totally missing the point, totally failing
to meet the challenge that you have been salivating for so badly, and
totally failing to remember anything I wrote about C on the mainframe to you
in various newsgroups. You got spanked on comp.lang.forth recently so I
guess you have more time to cruise the news since you're persona non-grata
more places every day.

Bye buddy. It's been real. And it's been fun. But it hasn't been real fun.

BZZT!! TOTAL FAIL!!


Rod into my killfile you go
Don't take it so hard buddy cause you know
You can't remember what you read
You misquote and foam instead
Got big problems with your head
Why'd you go off your meds?
So it's into my killfile you go

Your ISP will put you on suspension
Due to your total lack of reading comprehension
Too much coffee
Too much booze
Too much internet news
Buddy into my killfile you go

You've displayed a lack of common decency
As any usenet regular can see
In all those usenet groups
You failed to make a coups
You're all alone under your tree

Now the shoe has been thrown
You're the dog without a bone
Watching Home Alone
Is what you're gonna have to do
But that should be good enough for you

You miss all the latest poop
You attempted to regroup
But they all spoiled your soup
And it just didn't work out like you planned
Turns out babe you're more hot air than sand

You make up bizarre tangents of your own
The light's on but they're ain't nobody home
I knew it would come to this
So it's not hard to dismiss
A guy like you who burned out long ago
A candle in the wind just like that ho

Rod we warned you quite a lot about your end
Your endless thread highjacking did forfend
You'll lose all your friends and never make amends
Baby into my killfile you go

Don't let that big door hit you in the ass on your way out
Just take it like a man don't cry and pout
You overstayed your welcome
You can damn well go to hell come
Back when you get a fucking clue
We'll all be old and gray if you do
But we're all betting that you never do

I can't think of a whole lot finer
Than seeing you get sent back to the Minors
You're Windows 98 just isn't that great
But it's the only thing on your plate
So just turn it off and stop being a whiner

Nothing seems to work out like you planned
Although in your own mind you're so very grand
You hear that clapping sound I'm sure
Headfirst into that wagon of manure
But it's the sound of the clapping of one hand

Just keep riding that Pemberton train
Where all the insane people think they're sane
And convince yourself that you were not to blame
Just don't keep trying to sell us a ticket
Because all the sane people are insane

Yeah you got a fifty year plan
But that's like a sheep eating bran
You won't make it that far
Without a bike or a car
And your walkman didn't get you where you are

Rod with your old Windows box you still play
You seem to do it day and night and day
Intel's 80186 rules you're all a bunch of fools
And ARM what's up with that no one's ever heard of that
It will never beat my Wintel anyway
Seems that is all you ever have to say
Go away and let me have my dreams and play

Rod you know we won't stay waiting up for you
We've done more than we should have had to do
You can't respond to anything we say
No point to carry on that way
A conversation for one
Just isn't that much fun
Except that's all you ever seem to do
So it's into the killfile for you

Don't feel so bad and jealous all alone
Spend more time with your boyfriends on the phone
Just don't say we didn't warn that it would come to pass
That we'd say to fucking shove it up your ass!


__, _, __, __, __, _, _ __, __, __, ___ _, _, _
|_) / \ | \ |_) |_ |\/| |_) |_ |_) | / \ |\ |
| \ \ / |_/ | | | | |_) | | \ | \ / | \|
~ ~ ~ ~ ~ ~~~ ~ ~ ~ ~~~ ~ ~ ~ ~ ~ ~


___ _, ___ _, _,
| / \ | / \ |
| \ / | |~| | ,
~ ~ ~ ~ ~ ~~~


__, _, _ _,
|_ / \ | |
| |~| | | ,
~ ~ ~ ~ ~~~

[Rod Pemberton]

"Fritz Wuehler" <fr...@spamexpire-201205.rodent.frell.theremailer.net> wrote
in message

news:c1a7f27e11529162...@msgid.frell.theremailer.net...

> "Rod Pemberton" <do_no...@notemailntt.cmm> wrote:
>
> snip forever
>

It seems I struck a nerve. I don't know why. My post on comp.lang.misc was
legitimate, honest, and insightful, not inciteful. Your reply has gone
way overboard.

"The lady doth protest too much, methinks."

Sorry, that just popped into my head. A complete quote as a Freudian slip,
if you will ...

So, I've decided to see how you rank on the "Brad Jesness Memorial Kook
Appraisal Test". You rank as a "Journeyman Kook". I was impartial.

If I include the worst of my posts, even ones you're unaware of - all of
which were in response to other verbally abusive and hostile individuals who
were acting up yet again and deserved such treatment - I still rank FAR
below you. Yet, apparently you've classified me as "Kook First Class",
much above the "Journeyman Kook". Sometimes, you're just ludicrous and
laughable. Of course, I believe those posts of mine should be ignored.
They were just, IMO.

So, let's see. You've threatened to "filter" me, like what, five times now?
... If you finally grew a pair and did so, congrats! However, you are
still posting anonymously ... That's generally frowned upon in Usenet.
It's considered impolite. Reread the Usenet netiquette guides. So, that's
a major factor in being labeled a "kook" and "troll".

Besides, I think that's the best thing ... for you. You clearly have
tendencies that psychologists call "anti-social" and "hostility."
http://en.wikipedia.org/wiki/Hostility
http://en.wikipedia.org/wiki/Anti-social_behaviour

Unfortunately, my *fear* (very, very small, almost insignificant really) is
that what you've failed to understand about yourself is that you'll be back
clamoring to talk to me again. I don't doubt that at all. You use your
anonymity to allow yourself to express insults freely. Unfortunately, your
out-of-the-blue and uncalled for insults drive most people away. So, you're
left talking to those who will talk to you, like me, because I forgive, I'm
generous, and I'll talk. Apparently, you've created a mini-Hell for
yourself.

> [immature-and-nonsensical-anti-Rod-rant]
>

First, thanks for the rant. It shows you care, or are totally nuts ...
Although the latter is probably the truth, I won't assume that. You spent
some time on the poem, at least. I'm not sure who you thought you wrote it
about. It must've mostly come from your life, or you've got me confused for
someone else. If you thought it was about me, you never made it past a few
trivial surface details I posted online.

Second, dude, my post on comp.lang.misc was 100% serious. I'm sorry you
didn't grasp that, yet again. You're SO dismissive. All my posts are 100%
serious, except where there's a smiley or where I mark the sarcasm or
rhetoricalicality.

> Rod, you definitely have problems [...]

What problems? Be more specific. You're not me. How can you be certain?

> [...] and you're off your meds again.

That's what psychologists call "projection." They'd call that "forgetful"
too. I've responded to that claim by you at least twice now.

> Sorry but it's just not worth filtering through your bizarre

> off-topic thread hijacking rants [...]

That's what psychologists call "projection" too.

> [...] and endless lack of reading comprehension to get

> maybe one possible tidbit of interesting factoid.

That's what psychologists call "projection" too.

> You can't remember anything beyond one post and even
> within one post you usually have big problems. Sad.

That's what psychologists call "projection" too.

> I've already shot down all your best attempts at outsmarting me [...]

Oh, wait ... That's what psychologists call "delusional."

> [...] and you were never able to substantiate anything except

> your total willingness to argue about stuff you have no clue about.

That's what psychologists call "delusional" too.

> You're a true Cliff Claven!

I think you may have meant the "Cliff Clavin" character on the Cheers TV
show ... That's what mispronunciation gets you. You can look up stuff like
that on IMDB ... so that you don't get it wrong next time. However, your
bogus description of me fits the "Woody Boyd" character better. Forgetful?
And, you're showing your age ... That's a two to three decades old
reference. With the phenomenal amount of excellent tv and internet media
content during the past decade, you couldn't have come up with something
better? Was there a reason that you expected me to grasp the ancient
reference? That's not the type of show that interested me.
http://www.imdb.com/

> That last post of yours is a combination of totally missing the point,

> [...]

Well, I replied to what *you* wrote ... Did you miss your own point?

> [...] totally failing to meet the challenge that you have been salivating
> for so badly [...]

That's what psychologists call "delusional" too.

> [...] , and totally failing to remember anything I wrote

> about C on the mainframe to you in various newsgroups.

That's what psychologists call "delusional" too.

> You got spanked on comp.lang.forth recently [...]

That's what psychologists call "delusional" too.

> [...] so I guess you have more time to cruise the news

> since you're persona non-grata more places every day.

That's what psychologists call "wishful thinking" and "projection."

This is from the guy who just got kicked by John Levine, from
comp.compilers, a man I've only known as very nice ...

> Bye buddy.

I don't recall giving you permission to call me "buddy," chump.

Later chump.

> It's been real.

It has? No, it hasn't. At least, not from my perspective. I've been an
open book. I've used my real name. I've stated the truth. I've stated
what I know. I've stated what I believe. You chose to hide, insult, taunt,
make stuff up, bluff and BS. You've been too anonymous, too secretive, too
closed off, and too insulting for it to be real for me. The only thing real
were my replies to you, which you've utterly dismissed. IMO, you're a
"wuss." Man up! Use your real name. "Real" would be like one of the
assholes I had as a roomate in college. I had to deal with a few of them.
One of them ate my food, sold my books, stole my clothes, etc. Then, the
moron fell asleep and drooled all over his final exam project.

> And it's been fun. But it hasn't been real fun.

I didn't think so, but I offered you my abundant wisdom and eternal
forgiveness anyway. It could've been fun, if you had conversed on one of
the hundred plus topics I mentioned that I was interested in, or any topic -
except ancient IBM hearsay - for that matter ... You chose to make it not
fun. I put so much into that list, that I think I may have even had "cats"
and "dogs" on it ... Of course, that was on an alt.* group where there is
no topicality, unlike c.l.f. and c.l.m. which you just *SPAMMED*.

> BZZT!! TOTAL FAIL!!

You still don't understand that words don't hurt me. Do you? You don't
understand that power is both introverted and extroverted. I'm not affected
by your words, but clearly, you have been by mine. Clearly, you're not
powerful in regards to our "relationship."

> [poem]

Your poem was fruitless and pointless. Although, it flowed. But, I'd swear
you copied lame song lyrics, from old pop songs, and merged them for every
3rd or 4th line. Was that done by a Markov generator? And, again you
included another ancient reference (movie vs. tv). I'm truly surprised you
didn't mention James Kirk, Jean-Luc Picard, Wesley Crusher, a Womp Rat, Orcs
or Halflings, Hobbits, Boba Fett, J.R.R. Tolkien, Robert Heinlein, Philip
Dick, or Comic-Con. From the fantasy world of your poem, all that seems
right up your alley.

Imagine what you would have now *if* you had spent as much time on a Forth
ITC interpreter as you did on the poem attempting to attack me ... You
could've had the basic interpreter working. The fact that you don't is what
economists call a "lost opportunity cost." My Forth interpreter has had
lots of work put into it. That was before I ever started posting about it.
I also post only after I work on it and my other projects, as they please
me. It's clear you've got your priorities backwards: post first, attempt to
do something with your remaining time.


Rod Pemberton

[Marco van de Voort]

On 2012-05-07, BartC <b...@freeuk.com> wrote:
>> It's the procedural definition, rather than C. Most of the calls are not
>> even proper C (since they are stdcall)

.. if ..

> That's just a calling convention.

> It's just part of what *has* to be in C,

Then "C" is just syntax. Which was my point.

> if it's going to be used under Windows. My languages tended to use the
> same convention, but it's one of those things you sort out once, then
> forget about for years.

True. But it is nevertheless not a C api. It is a procedural API, for which
some C compilers have added their own non standard extension.

> You had to take more care with callback functions; Windows assumes
> (presumably) it's calling a Visual C function, which saves certain
> registers. So your language has to do the same (which mine didn't,
> meaning some inline asm in a few strategic places).

You have to be more specific here. What do you mean here? Stdcall or
safecall (IOW stdcall with SEH sensitivities?). If the latter, then that is
C++ not C, since C afaik doesn't have exceptions.

>> More importantly, if you _wouldn't_ have used an own language, but rather
>> a fairly major other language (Delphi, VB come to mind), would you
>> actually have needed the raw interfaces much?
>
> It would have meant less work certainly; anything involving a Windows API
> (and a C one to a lesser extent) meant translating hundreds of #defines,
> macros, structs and function declarations into an acceptable format for my
> language.

No. In general you get that from the vendor of your toolchain since that is
an one off effort. Just like that you have to install MSDN (Windows doesn't
come with it) as part of a VS install.

So that leaves only the latency of translation, and the more fringe areas
where this might actually happen. Mind you, these generally are the cases
where your VS version turns out to be outdated anyway :)

> But as for actually using a mainstream language for serious work, sorry I
> can't remember the last time I did that. I guess the APIs are just presented
> as part of the language that is being used, so you're not even aware of
> calling foreign functions. I think you do learn more doing things the hard
> way.

And waste more time. The company I work for prides itself on doing non
standard and difficult work, but even we can't take forever. Productivity
remains the first priority, and flexibility only second.

>>> the newer CreateFile with fopen, for example).
>>
>> It is more logical to use the file I$/O that comes with your language.
>
> Yes, but because I'm not programming bare hardware anymore, I have to access
> i/o via the OS, and I chose to do this indirectly via the C runtime, and
> this was done via wrappers to implement my idea of a file API.

I thought the C open was "fopen" not createfile?