BLISS vs. C: Which is the better language for VMS?
goath...@wkuvx1.bitnet
among Ed Heinrich, Jamie Hanrahan, and me (Hunter) about BLISS vs. C.
We're making the comments public now to see what other people think.
I'm also cross-posting this to vmsnet.internals and to comp.arch,
where a BLISS discussion has been going on the past few days.
Our BLISS seminar scheduled for DECUS was cancelled because too few
people signed up for it. However, there appears to be a *lot* of
interest in BLISS, because 58 people have picked up the BLISS article
from my file server (send SEND BLISS-ARTICLE-PS in a mail message to
FILE...@WKUVX1.BITNET) since I announced it the other day. I don't
have any idea how many people have picked it up via ftp from
ftp.spc.edu ([.MACRO32]). (You must have access to VMS to unpack the
PostScript article.)
It all started with the following comment that I made to Jamie:
HG> For years, DEC
HG> said to program in BLISS to protect yourself from machine changes; now that
HG> Alpha's coming out, they're saying we should use C. I, for one, loathe C
HG> and love writing in BLISS. Hopefully, DEC will start emphasizing BLISS
HG> too, and there'll be enough interest to do the seminar in the fall.
Ed then sent Jamie the following message:
EH> Hunter forwarded this message on to me. Seeing that you are interested in
EH> BLISS and that, given your DECUS "relationship", I was wondering if you
EH> could formally express a WISH that Digital make BLISS available under
EH> Alpha/VMS in a manner similiar to the way that Macro-32 is bundled on a
EH> VAX/VMS system.
EH>
EH> There are people, such as Hunter and I, who really enjoy programming in
EH> BLISS, and who listened to DEC years ago when they said that BLISS is
EH> portable and will allow you to recompile VMS code under "future" hardware
EH> platforms. Now that Alpha is being announced, DEC appears to be saying that,
EH> although a LOT of VMS is written in BLISS and 3rd party products are also
EH> coded in BLISS, that they aren't sure they want to make BLISS generally
EH> available under Alpha.
EH>
EH> BLISS is the ONLY language that is available, on BOTH VAX and Alpha, to
EH> write privileged code in. DEC (Alpha) C will allow access to internal
EH> VMS routines, but as you well know, VAX C doesn't. (Unless you want to
EH> do funky things things, i.e., fixup CALLS/RET instructions to be JSB/RSB
EH> at runtime. I Saw the post about privileged code in C and have seen an
EH> example of a program that, at execution time, patches the C CALLS
EH> instructions to be JSBs, its UGLY! The JSB pragma only works for routines
EH> internal to the module, not for externs so that is USELESS).
EH>
EH> If DEC would say that BLISS will be bundled w/ Alpha, then we would really
EH> have a portable environment that would allow us to keep the SAME source
EH> code, conditionalized of course w/ %IF statements, for both VAX and Alpha
EH> VMS privileged code. I would appreciate it if you could, in your position
EH> of heading up the internals SIG, request that DEC commit to BLISS for the
EH> common man.
To which Jamie responded:
JH> This would be a reasonable project (white paper) for the internals working
JH> group. What we need to do is present a case to DEC that establishes that it
JH> is in their business interest to do this.
Having said all of that, Jamie and I got into discussions of the merits of
BLISS vs. C:
JH> (Personally, I prefer C's strong typing to Bliss's laissez-faire
JH> attitude... There are some nice things in Bliss, but if I'm going to
JH> code in a high-level language, I want it to do type checking,
JH> including argument checking, for me... also, Bliss's structure
JH> definitions are obscure and awkward to say the least, particularly for
JH> nested structures.)
I responded and Jamie wrote:
JH> Now, on to the fun stuff (maybe we should move this to the newsgroup and
JH> let others join in):
HG> Hmmm. Valid complaints about BLISS, but I find it to be a much more
HG> logical language than C. It has many of the same powerful features
HG> (multiple assignments in one expression) but isn't nearly as cryptic.
JH> I've lost count (already -- and I haven't been working in Bliss that
JH> long) of the number of times I've been bitten by one . too many or too
JH> few. C would have caught these at compile time! This is *not* a
JH> trivial thing to lose.
Valid point. More in a minute....
JH> Also re type checking, if I (in C) define ucbptr as a pointer to a
JH> struct of type ucb, lo and behold the compiler will not let me move
JH> anything that ISN'T a pointer to a ucb into that field. Bliss just
JH> doesn't care and will gladly let you shoot yourself in the foot just
JH> as easily as Macro will.
True. However, that's never been a problem for me in BLISS or MACRO.
Having spent most of the last six years writing almost exclusively in
MACRO, I'm not used to having to define specific types of structs,
etc., so it's not much of a problem for me. One of the big advantages
for me of moving from MACRO to BLISS has been the ability to use names
like UCB when dealing with specific registers in kernel-mode code
(UCB for R5, for example). Just naming variables correctly goes a
*long* way toward solving problems that C's type checking enforces.
JH> And it is utterly ludicrous to have to write "increment A by one" as
JH>
JH> A = .A + 1;
JH>
JH> The . should be required on both sides of the =, or on neither. This
JH> is completely opposite to *every* other language I've worked with --
JH> INCLUDING Macro.
Well, the dot notation *always* throws people off when they first
start using it (it did me). But once you think about it, it all makes
sense. Variable names in BLISS *always* refer to the *address* of the
data, not the data itself. The "." is used to fetch the value stored
at that address. If you wrote
A = A + 1;
you'd be taking the address A represents (say 200) and incrementing by
one, storing it back at 200. To increment the value stored at address
200, the "." is used to fetch that value.
BLISS is an expression language. There are no statements; everything
has a value. You can choose to ignore that value, but everything has
one. This means that the left side of the expression above could have
been any sequence that generates a valid address. For example (and
I must admit that this starts getting a little confusing until you
think about it), you could write:
B = A; !Store the address A (200) at B (204)
.B = .A + 1; !Increment value at A and store back in A
The value of ".B" is the address of A, so .A+1 is stored back in A.
This provides for some very flexible programming, though you must be
careful (and document stuff like that).
JH> Re the problems with structure defs in Bliss, someone told me "yeah,
JH> but you can use SDL for structure definitions", to which I replied, "I
JH> rest my case". If the language needs another software package to build
JH> data definitions for it, then the language is broken!
I will agree that BLISS strongly lacks decent structure defs. *If* DEC
made SDL available to everyone (by bundling it with VMS!!!), the
problem is, I think, solved. BLISS's structure defs are not really
any different from MACRO's---using SDL lets you generate the symbols
for *both* languages (indeed, all (most?) of the others too).
However, BLISS *does* let you define how a STRUCTURE is to be
referenced. In essence, it's like writing a macro that lets you
make a structure reference any way that is necessary.
HG> And, in general, there are fewer ways to accomplish the same thing---seems
HG> like C will let you do anything a dozen different ways, leading to
HG> confusion when different people work on the same programs.
JH> This is just a matter of idioms. After you work with C a little bit
JH> you get used to most of the common idioms and they don't bother you
JH> any more.
Well, maybe you get used to it, but I don't think you should *have* to
get used to it.
HG> C just doesn't sit well on VMS. Everything seems like a work-around when
HG> calling system services and run-time library routines.
JH> Nyah. The only problem here is if you use VMS string-handling
JH> routines *and* the C RTL. If you stick to all descriptor'd strings,
JH> things work just as easily as in Macro or Bliss.
True. But that means you can't use the internal string stuff with
your descriptored strings (not without messing with adding nulls to
the end but not counting them in the length, etc.).
JH> otoh, there are lots of nice things re string handling in the C RTL.
JH> And I've never found the problems to be that tough to overcome.
No, but it's a pain in any case.
Now, new things:
BLISS's macro facility is more powerful than that of any other
language I've ever seen. Virtually everyone who has used BLISS agrees
with this. Matt Kirk (ki...@tallis.enet.dec.com) posted in comp.arch:
MK> The two things I like about Bliss are the macro facility, which beats
MK> the pants off C and most other languages I've tried, and that (at least
MK> with the Digital variants) you can write systems level code easily. So
MK> some of the code that I would otherwise have had to write in Macro I can
MK> write in Bliss.
If you've ever seen the source to Matt Madison's MX, you'll know just
what you can do with BLISS macros! 8-)
To not leave anything out, Matt Kirk also says:
MK> Otherwise, I much perfer C++. Bliss is a bit more flexible because you
MK> have virtually no requirements as to how you do what you must do, but
MK> C++ (or C) provides much more support for what I need to do.
Which isn't systems-level (i.e., privileged) programming, I'll venture.
The *biggest* reason I prefer BLISS to C is that, with BLISS, you know
exactly what you're getting: whatever you tell the compiler to
generate. BLISS has no run-time support, so you never have to worry
about the compiler generating a call to an external BLISS run-time
routine. This is invaluable when trying to write privileged
code---with C, you have to make sure you don't make any calls to
built-in functions when running in kernel mode (depending on what you
call) or at elevated IPL (since you *will* page fault). With BLISS,
you never have to worry about external calls generated by the compiler
*because it doesn't make any*! The *only* way an external call is
made is if you call one of the system service or a VMS run-time
library routine (or another external module). The compiler doesn't
build in calls to its own run-time library because there isn't one.
This gets back to the heart of this discussion: BLISS *is* a better
systems programming language under VMS than C because you can write
systems-level code in it *without* regard for a compiler's run-time
support. The only other language for which this is true is MACRO-32.
C lets you do most of it, but you have to be *very* careful (and there
are no JSBs, no macros that will elevate IPL for you and acquire
spinlocks, etc.).
The problem with DEC preaching C for Alpha is that that means you
*cannot* write code for VAX VMS that will compile without modification
on Alpha VMS, since any calls to system routines (the EXE$ routines,
etc.) have to be done via JSB, which C doesn't support. The only
thing I've found that BLISS lacks is direct support for JMPs
(though the compiler can be fooled into producing them).
And BLISS is a GOTO-less language! 8-)
Well, I think I'll rest my case for now. Comments from anyone else?
Hunter
------
Hunter Goatley, VMS Systems Programmer, Western Kentucky University
goath...@WKUVX1.BITNET, 502-745-5251
Matthew B. Kirk
In article <1992Apr20....@wkuvx1.bitnet>, goath...@wkuvx1.bitnet writes...
>This message contains the text of several personal e-mail messages
>among Ed Heinrich, Jamie Hanrahan, and me (Hunter) about BLISS vs. C.
>We're making the comments public now to see what other people think.
.
.
>To not leave anything out, Matt Kirk also says:
>
>MK> Otherwise, I much perfer C++. Bliss is a bit more flexible because you
>MK> have virtually no requirements as to how you do what you must do, but
>MK> C++ (or C) provides much more support for what I need to do.
>
>Which isn't systems-level (i.e., privileged) programming, I'll venture.
Mostly correct. (though I differ slightly in what is systems level
programming). For example, I've used Bliss to write exception
handlers for hardware test software that explicitly modifies the
instruction stream and registers. Not privileged, but what I'd
consider systems level. C didn't provide sufficient control over
register access to do this (for the uninitiated, in Bliss you can
essentially declare almost any call standard, and you can map
variables to specific registers).
The solution, of course, is to write in mixed Bliss and C. Code that
requires lots of system code is written in Bliss - code that doesn't
is written in C (C++). Not ideal, but...
Matt
=============================================================================
Matthew Kirk ki...@tallis.enet.dec.com
All opinions expressed here are mine and do not reflect those of Digital
Equipment Corporation.
=============================================================================
william E Davidsen
| This message contains the text of several personal e-mail messages
| among Ed Heinrich, Jamie Hanrahan, and me (Hunter) about BLISS vs. C.
| We're making the comments public now to see what other people think.
Having programmed in BLISS and C I can assure you that I'd go back to
selling used cars before I'd program in BLISS again. Now you know what I
think.
| HG> For years, DEC
| HG> said to program in BLISS to protect yourself from machine changes; now that
| HG> Alpha's coming out, they're saying we should use C. I, for one, loathe C
| HG> and love writing in BLISS. Hopefully, DEC will start emphasizing BLISS
| HG> too, and there'll be enough interest to do the seminar in the fall.
Do you mean "program in BLISS to protect yourself from machine
changes" as in machine changes will be easier, or as in there is no
BLISS for other machines so you will never have to port your code. My
feeling was always the latter, and it seems to have failed like garlic
keeping away vampires.
| EH> There are people, such as Hunter and I, who really enjoy programming in
| EH> BLISS, and who listened to DEC years ago when they said that BLISS is
| EH> portable and will allow you to recompile VMS code under "future" hardware
| EH> platforms. Now that Alpha is being announced, DEC appears to be saying that,
| EH> although a LOT of VMS is written in BLISS and 3rd party products are also
| EH> coded in BLISS, that they aren't sure they want to make BLISS generally
| EH> available under Alpha.
Sounds like a good decision. Proprietary code costs money to maintain,
and DEC might well save money by dropping some of the least used and
liked products, like BLISS and VMS.
| EH> BLISS is the ONLY language that is available, on BOTH VAX and Alpha, to
| EH> write privileged code in. DEC (Alpha) C will allow access to internal
| EH> VMS routines, but as you well know, VAX C doesn't. (Unless you want to
| EH> do funky things things, i.e., fixup CALLS/RET instructions to be JSB/RSB
| EH> at runtime. I Saw the post about privileged code in C and have seen an
| EH> example of a program that, at execution time, patches the C CALLS
| EH> instructions to be JSBs, its UGLY! The JSB pragma only works for routines
| EH> internal to the module, not for externs so that is USELESS).
This is like extolling the virtues of your garbage truck because your
BMW is broken. If DEC C can't do something it should, then obviously the
C should be fixed.
| EH> If DEC would say that BLISS will be bundled w/ Alpha, then we would really
| EH> have a portable environment that would allow us to keep the SAME source
| EH> code, conditionalized of course w/ %IF statements, for both VAX and Alpha
| EH> VMS privileged code. I would appreciate it if you could, in your position
| EH> of heading up the internals SIG, request that DEC commit to BLISS for the
| EH> common man.
As a high level assembler for system internals BLISS makes sense.
Bundling it with every machine and encouraging it's use for anything
other than internals is probably a bad idea, both for DEC and the
programmers who use it. Like it or not, C is widely used and portable,
has a standard, and multiple vendors. It's a better choice for
portability.
| JH> (Personally, I prefer C's strong typing to Bliss's laissez-faire
| JH> attitude... There are some nice things in Bliss, but if I'm going to
| JH> code in a high-level language, I want it to do type checking,
| JH> including argument checking, for me... also, Bliss's structure
| JH> definitions are obscure and awkward to say the least, particularly for
| JH> nested structures.)
"obscure and awkward" is a polite way of saying it.
| HG> Hmmm. Valid complaints about BLISS, but I find it to be a much more
| HG> logical language than C. It has many of the same powerful features
| HG> (multiple assignments in one expression) but isn't nearly as cryptic.
See the example following for some "isn't nearly as cryptic."
| JH> I've lost count (already -- and I haven't been working in Bliss that
| JH> long) of the number of times I've been bitten by one . too many or too
| JH> few. C would have caught these at compile time! This is *not* a
| JH> trivial thing to lose.
The problem is that the basic design decision is that the name of a
variable means the address, rather than the value. C allows you to take
the address, assuming thast the content is more generally what you want.
Many people get bitten in C when using multiple levels of indirection,
but BLISS always needs one more level and is that much less intuitive to
most people.
Here is the section about syntax, from people who still use the
language.
| JH> And it is utterly ludicrous to have to write "increment A by one" as
| JH>
| JH> A = .A + 1;
| JH>
| JH> The . should be required on both sides of the =, or on neither. This
| JH> is completely opposite to *every* other language I've worked with --
| JH> INCLUDING Macro.
|
| Well, the dot notation *always* throws people off when they first
| start using it (it did me). But once you think about it, it all makes
| sense. Variable names in BLISS *always* refer to the *address* of the
| data, not the data itself. The "." is used to fetch the value stored
| at that address. If you wrote
|
| A = A + 1;
|
| you'd be taking the address A represents (say 200) and incrementing by
| one, storing it back at 200. To increment the value stored at address
| 200, the "." is used to fetch that value.
I have reluctantly deleted more at this point.
Please send all flames to alt.flame or by mail, I realize that there
are those out there who think BLISS is the language of Ken's chosen
people.
--
- bill davidsen (davi...@crd.ge.com)
GE Corp. R&D Center; Box 8; Schenectady NY 12345
By analysis of usenet source, the hardest part of C to use is the comment
goath...@wkuvx1.bitnet
> In article <1992Apr20....@wkuvx1.bitnet>, goath...@wkuvx1.bitnet writes...
>
>>MK> have virtually no requirements as to how you do what you must do, but
>>MK> C++ (or C) provides much more support for what I need to do.
>>
>>Which isn't systems-level (i.e., privileged) programming, I'll venture.
>
> Mostly correct. (though I differ slightly in what is systems level
> programming). For example, I've used Bliss to write exception
> handlers for hardware test software that explicitly modifies the
> instruction stream and registers. Not privileged, but what I'd
> consider systems level. C didn't provide sufficient control over
> register access to do this (for the uninitiated, in Bliss you can
> essentially declare almost any call standard, and you can map
> variables to specific registers).
>
systems-level code, but it does do that well.
> The solution, of course, is to write in mixed Bliss and C. Code that
> requires lots of system code is written in Bliss - code that doesn't
> is written in C (C++). Not ideal, but...
>
Yeah. Maybe it's because of my MACRO background, but I prefer BLISS
for user-mode code too. It's just as easy for me to write in BLISS as
it is in C when dealing with strings, I/O, etc.
Eric Thomas, SUNET
In article <1992Apr20....@wkuvx1.bitnet>, goath...@wkuvx1.bitnet writes...
>Our BLISS seminar scheduled for DECUS was cancelled because too few
>people signed up for it.
In my opinion, the main problem with BLISS is that you have to buy it. We don't
have money to buy a DEC-specific language that doesn't compile on unix
playstations -> no BLISS. It is pretty difficult to justify the purchase of
that kind of compiler when you don't HAVE to write bunches of system codes as
part of whatever the machine was bought for. Unless, of course, you get it free
from some higher education consortium deal.
>HG> Hmmm. Valid complaints about BLISS, but I find it to be a much more
>HG> logical language than C. It has many of the same powerful features
>HG> (multiple assignments in one expression) but isn't nearly as cryptic.
From the small amount of BLISS code I have seen, it has a very significant
advantage over C: it wasn't designed by someone who looked at his keyboard,
rubbed his hands in gleeful anticipation, and said "Now, let's see which of the
symbols I haven't found a use for yet..." :-) While this is basically
irrelevant to US programmers, over here it means that my code doesn't look
like:
Ainclude <stdio.h>
if (aOi++E X= 3) a
printf("Error with element %d.En", i);
flags != ERR_IN_ELEMENT;
a
>JH> otoh, there are lots of nice things re string handling in the C RTL.
>JH> And I've never found the problems to be that tough to overcome.
That is one of my pet peeves. The C language and standard library do NOT have
ANY support for STRINGS, ie things defined by an address, a length, and a
maximum length for R/W strings. The C language has support for chunks of
contiguous memory defined by their address, their address, and, for R/W
strings, their address. I have had to maintain a C application totalling
something like 1M of code, and most of the problems arose from sprintf()'s into
buffers that happened to be too small for some input value. What can you do?
Any unixoid life form will tell you with a shrug and a side glance that says a
lot about his appraisal of your IQ that you should "just double the size of the
buffer and recompile, what's the deal?" :-) Calculating the amount of space
that a sprintf() is going to require and using a malloc() is at best a major
pain in the chairwarmer (don't you just love counting the size of text
literals, and adjusting when you change the text?), at worst impossible. There
is, OBVIOUSLY, no way to tell sprintf that your buffer has only got 256 bytes
and it shouldn't happily overlay whatever follows if, for any reason, there
isn't enough space. Why should one want to do that? It prevents fun things like
Internet worms ;-)
>BLISS's macro facility is more powerful than that of any other
>language I've ever seen.
C does not have a macro facility, that is one of its major drawbacks. Oh, it
has a text-based pattern substitution facility, all right, but that simply
doesn't cut it.
Concrete example #1: I have to declare a table of names, flags, and functions.
I want to define it with something like:
ENTRY("duh", flag_value, procedure_name)
Well that would be trivial, except for each entry I also have to declare the
procedure in advance - outside the table, obviously, and I surely want the
ENTRY statement to take care of it for me. With a macro facility, I'd generate
the 'void procedure(whatever);' on the fly, save the other arguments, and spit
them out when the last entry is reached. Sorry, can't do. Well I did manage to
kludge it with an include file I #include'd twice with a different macro
expansion, but that's only because it was a simple problem.
Concrete example #2: I want to write a macro that does something obfuscated,
like generate 5 lines of code full of casts. But I want to do something
different depending on the parameters - for instance, if the first one starts
with a double quote, I want to append a "\n" to make unix-style file routines
happy, whereas if it's the address of a buffer I want to use strcat instead.
Then if the second and third arguments are the same, I need to do something
specific. Well I end up with several macros which are almost, but not quite the
same and which I have to keep in synch, and I have to remember the subtle
differences in the names... If I make a mistake and use the wrong name, it will
compile happily, but not do what I thought :-)
>The problem with DEC preaching C for Alpha is that that means you
>*cannot* write code for VAX VMS that will compile without modification
>on Alpha VMS, since any calls to system routines (the EXE$ routines,
>etc.) have to be done via JSB, which C doesn't support.
Maybe it just means DEC doesn't want you to write Alpha device drivers? :-)
Eric
goath...@wkuvx1.bitnet
> |HG> For years, DEC
> |HG> said to program in BLISS to protect yourself from machine changes; now that
> |HG> Alpha's coming out, they're saying we should use C. I, for one, loathe C
> |HG> and love writing in BLISS. Hopefully, DEC will start emphasizing BLISS
> |HG> too, and there'll be enough interest to do the seminar in the fall.
>
> Do you mean "program in BLISS to protect yourself from machine
> changes" as in machine changes will be easier, or as in there is no
> BLISS for other machines so you will never have to port your code. My
> feeling was always the latter, and it seems to have failed like garlic
> keeping away vampires.
>
DEC layered products, your program isn't going to be very portable to
another platform no matter what you do (unless you write or purchase
similar routines). I try to go for a VMS-feel to everything I do
(since VMS is what I do) and that means I use the callable utility
routines like the CLI stuff, LIB$ routines, system services, etc.
These programs aren't going to port to UNIX without a lot of work
anyway, so writing in C just for porting to UNIX doesn't make sense in
this case.
Whether you like VMS or not, people who use it like to see consistent
interfaces to utilities. *If* I was writing something that had uses
beyond VMS, then yes, I too would use C for it.
So I'll add to my previous comments: systems programming also includes
programs that are integrated with the system. Programs ported from/to
UNIX are not usually integrated with VMS.
[...]
> |EH> platforms. Now that Alpha is being announced, DEC appears to be saying that,
> |EH> although a LOT of VMS is written in BLISS and 3rd party products are also
> |EH> coded in BLISS, that they aren't sure they want to make BLISS generally
> |EH> available under Alpha.
>
> Sounds like a good decision. Proprietary code costs money to maintain,
> and DEC might well save money by dropping some of the least used and
> liked products, like BLISS and VMS.
>
Here, here....
> | EH> BLISS is the ONLY language that is available, on BOTH VAX and Alpha, to
[...]
>
> This is like extolling the virtues of your garbage truck because your
> BMW is broken. If DEC C can't do something it should, then obviously the
> C should be fixed.
>
Ed and I both agree with this. But they haven't yet and nothing I've
seen indicates that they're going to.
> As a high level assembler for system internals BLISS makes sense.
> Bundling it with every machine and encouraging it's use for anything
> other than internals is probably a bad idea, both for DEC and the
> programmers who use it. Like it or not, C is widely used and portable,
> has a standard, and multiple vendors. It's a better choice for
> portability.
>
Again, I think it depends on what you're writing. Not *all*
applications are automatically portable (in either direction).
> Please send all flames to alt.flame or by mail, I realize that there
> are those out there who think BLISS is the language of Ken's chosen
> people.
It is true that my interest in BLISS originated with the VMS source
listings. But coming from MACRO, BLISS has been a very painless
language to adopt. I don't use BLISS because DEC uses it---I
use it because it gives me the power and flexibility of MACRO
without the hassles.
> --
> - bill davidsen (davi...@crd.ge.com)
> GE Corp. R&D Center; Box 8; Schenectady NY 12345
> By analysis of usenet source, the hardest part of C to use is the comment
Ain't it the truth....
Peter da Silva
level languages than C, which lets you write a COMPLETE operating system in
them as you can't in C. It is essential that such a systems language exist, but
should you do a majority of systems programming in them? I don't think so.
You can get used to the weirdnesses of these non-typed languages, but they
are a fertile source of bugs until you do. C's ittle idioms are much easier
to learn.
There are some other languages that actually come in two versions: a type-safe
one, and an untyped subset that just handles machine objects. I think that's
a better solution to avoid the problem of switching languages for application
areas.
Anyone ever built a lisp-like low level language?
--
/F{findfont exch scalefont setfont}def /S{moveto show}def /T{/Times-Roman F}def
8 T(Ferranti International Controls Corporation)24 28 S(+1 713 274 5180)24 12 S
(Sugar Land, TX 77487-5012)24 20 S 12 /Courier F(`-_-')320 32 S( 'U` )320 16 S
12 T(Peter da Silva)24 36 S 16 T(Have you hugged your wolf today?)358 24 S
goath...@wkuvx1.bitnet
so it will make it to comp.arch (Ed doesn't have access to NEWS).
I'd also like to mention that I'm not trying to incite yet another
language war; rather, I'm just trying to point out the features of
BLISS, since most people don't know much about it.
Hunter
------
Hunter Goatley, VMS Systems Programmer, Western Kentucky University
goath...@WKUVX1.BITNET, 502-745-5251
Ed's message:
> JH> (Personally, I prefer C's strong typing to Bliss's laissez-faire
> JH> attitude... There are some nice things in Bliss, but if I'm going to
> JH> code in a high-level language, I want it to do type checking,
> JH> including argument checking, for me... also, Bliss's structure
> JH> definitions are obscure and awkward to say the least, particularly for
> JH> nested structures.)
>
Obscure until you work w/ BLISS a bit. Anything that does structure
definitions is usually obscure at first, C's variant definitions sure
aren't clear at first glance. BLISS HAS the capability to DEFINE
structures that it will insure only the members of the structure are
referenced, I don't have a BLISS manual handly, but I think the syntax
is SET.
[...]
> JH> Also re type checking, if I (in C) define ucbptr as a pointer to a
> JH> struct of type ucb, lo and behold the compiler will not let me move
> JH> anything that ISN'T a pointer to a ucb into that field. Bliss just
> JH> doesn't care and will gladly let you shoot yourself in the foot just
> JH> as easily as Macro will.
>
Yes, if R5 has a UCB address and R4 a PCB, then Macro will allow you to
do:
MOVL UCB$L_IRP(R4), R1
and BLISS will allow irp = .pcb [UCB$L_IRP], but YOU DO have to go
out of your way, purposefully, type pcb instead of UCB, to do it.
Again, the SET TES structure will prevent this.
> True. However, that's never been a problem for me in BLISS or MACRO.
> Having spent most of the last six years writing almost exclusively in
> MACRO, I'm not used to having to define specific types of structs,
> etc., so it's not much of a problem for me. One of the big advantages
> for me of moving from MACRO to BLISS has been the ability to use names
> like UCB when dealing with specific registers in kernel-mode code
> (UCB for R5, for example). Just naming variables correctly goes a
> *long* way toward solving problems that C's type checking enforces.
>
> JH> And it is utterly ludicrous to have to write "increment A by one" as
> JH>
> JH> A = .A + 1;
> JH>
> JH> The . should be required on both sides of the =, or on neither. This
> JH> is completely opposite to *every* other language I've worked with --
> JH> INCLUDING Macro.
>
> Well, the dot notation *always* throws people off when they first
> start using it (it did me). But once you think about it, it all makes
> sense. Variable names in BLISS *always* refer to the *address* of the
> data, not the data itself. The "." is used to fetch the value stored
> at that address. If you wrote
>
> A = A + 1;
>
> you'd be taking the address A represents (say 200) and incrementing by
> one, storing it back at 200. To increment the value stored at address
> 200, the "." is used to fetch that value.
>
BLISS is CONSISTENT with treating EVERYTHING as an ADDRESS, whereas with
C do I need &a, a, *a, etc. Also, talk about confusing, if I have a
structure in BLISS, it is ALWAYS .pcb [PCB$L_PID], whereas in C, is it:
pcb.PCB$L_PID OR pcb->PCB$L_PID ?????
Granted, VAX Macro spoils you, they have MOVL and MOVAB, but in Macro-11,
MOVW got the contents whereas, MOVW #A obtained the address of A, NOT
the contents. The point being, all languages have their semantics,
BLISS is MORE consistent, in my humble opinion, than C, although it
DOES REQUIRE working in the language before one can become comfortable.
The fact that every reference to any variable is ALWAYS an address,
is very powerful since it allows for arithmetic operations to be
easily performed on addresses, something that in C often requires
extra work, i.e., defining x_ptr to be a pointer to X, simply to appease
the compiler, even NO additional hardware instructions will be generated.
>
> [...]
>
> HG> C just doesn't sit well on VMS. Everything seems like a work-around when
> HG> calling system services and run-time library routines.
>
> JH> Nyah. The only problem here is if you use VMS string-handling
> JH> routines *and* the C RTL. If you stick to all descriptor'd strings,
> JH> things work just as easily as in Macro or Bliss.
>
Also, BLISS, like MACRO, allows for KEYWORD macros, which MAKES calling
system services A LOT easier. In C, you HAVE to insure the order of
parameters when calling systm services and include all the parameters.
The use of keyword macros makes system service calling easier and less
prone to bugs due to a missing or out of sequence parameter.
> True. But that means you can't use the internal string stuff with
> your descriptored strings (not without messing with adding nulls to
> the end but not counting them in the length, etc.).
>
> JH> otoh, there are lots of nice things re string handling in the C RTL.
> JH> And I've never found the problems to be that tough to overcome.
>
> No, but it's a pain in any case.
>
Plus, zero terminate strings are highly inefficient! Counted strings are
VERY efficient. BLISS lends itself to counted strings.
> Now, new things:
> [...]
>
>
> The *biggest* reason I prefer BLISS to C is that, with BLISS, you know
> exactly what you're getting: whatever you tell the compiler to
> generate. BLISS has no run-time support, so you never have to worry
> about the compiler generating a call to an external BLISS run-time
> routine. This is invaluable when trying to write privileged
> code---with C, you have to make sure you don't make any calls to
> built-in functions when running in kernel mode (depending on what you
> call) or at elevated IPL (since you *will* page fault). With BLISS,
> you never have to worry about external calls generated by the compiler
> *because it doesn't make any*! The *only* way an external call is
> made is if you call one of the system service or a VMS run-time
> library routine (or another external module). The compiler doesn't
> build in calls to its own run-time library because there isn't one.
>
The other thing that BLISS allows, that C doesn't, although you can
play some linker games, but WHY should I have to bother, is EXPLICIT
CONTROL over Psects. Writing privileged code sometimes requires this
control, e.g., determining the length of a routine to load into pool
allocated for an AST is easier in BLISS than in C, having certain
routines live in one Psect while other reside in another for locking
memory down is also easier in BLISS.
> This gets back to the heart of this discussion: BLISS *is* a better
> systems programming language under VMS than C because you can write
> systems-level code in it *without* regard for a compiler's run-time
> support. The only other language for which this is true is MACRO-32.
> C lets you do most of it, but you have to be *very* careful (and there
> are no JSBs, no macros that will elevate IPL for you and acquire
> spinlocks, etc.).
>
C ALSO does NOT allow things, such as return to caller's caller, which, while
NOT necessarilly GOOD coding pratices, are the way that things WORK in
VMS. BLISS, while there is no language construct for these things either,
cna be made to execute JMP instructions via linkage declarations. In
addition, BLISS allows access to HARDWARE instructions when necessary.
If I decide I need to perform a CRC instruction in BLISS I can directly
access it, in C I must rely on the existance of a LIB$ routine to do
the CRC calculation for me.
> The problem with DEC preaching C for Alpha is that that means you
> *cannot* write code for VAX VMS that will compile without modification
> on Alpha VMS, since any calls to system routines (the EXE$ routines,
> etc.) have to be done via JSB, which C doesn't support. The only
> thing I've found that BLISS lacks is direct support for JMPs
> (though the compiler can be fooled into producing them).
>
> And BLISS is a GOTO-less language! 8-)
>
> Well, I think I'll rest my case for now. Comments from anyone else?
>
-------------------------------------------------------------------------------
Ed Heinrich, Novell, Inc. Sandy, Utah
ed_he...@npd.Novell.COM
"it's NOT the kill, it's the thrill of the chase"
-------------------------------------------------------------------------------
ma...@infocomm.com
JH> (Personally, I prefer C's strong typing to Bliss's laissez-faire
JH> attitude... There are some nice things in Bliss, but if I'm going to
JH> code in a high-level language, I want it to do type checking,
JH> including argument checking, for me... also, Bliss's structure
JH> definitions are obscure and awkward to say the least, particularly for
JH> nested structures.)
JH> Also re type checking, if I (in C) define ucbptr as a pointer to a
JH> struct of type ucb, lo and behold the compiler will not let me move
JH> anything that ISN'T a pointer to a ucb into that field. Bliss just
JH> doesn't care and will gladly let you shoot yourself in the foot just
JH> as easily as Macro will.
I generally agree with this advantage of C. C is simply a "higher" level
language than BLISS is.
HG> The *biggest* reason I prefer BLISS to C is that, with BLISS, you know
HG> exactly what you're getting: whatever you tell the compiler to
HG> generate. BLISS has no run-time support, so you never have to worry
HG> about the compiler generating a call to an external BLISS run-time
HG> routine. This is invaluable when trying to write privileged
HG> code---with C, you have to make sure you don't make any calls to
HG> built-in functions when running in kernel mode (depending on what you
HG> call) or at elevated IPL (since you *will* page fault). With BLISS,
HG> you never have to worry about external calls generated by the compiler
HG> *because it doesn't make any*! The *only* way an external call is
HG> made is if you call one of the system service or a VMS run-time
HG> library routine (or another external module). The compiler doesn't
HG> build in calls to its own run-time library because there isn't one.
Actually, the only call to an external runtime routine that I've ever seen
C generate is the "magic" it does to build the "main(argc, argv)" argument
list which it ONLY does for the special case function/procedure "main".
I've got lots of C programs that were never linked with any C runtime
library at all. They simply didn't use anything having to do with c style
strings, and/or I/O.
I must admit that the number of C programs that I've ever worked on that
did ANY floating point stuff has been close to zero, so I'm not sure if any
automatic RTL calls are generated to deal with this.
HG> This gets back to the heart of this discussion: BLISS *is* a better
HG> systems programming language under VMS than C because you can write
Lets qualify that a little ... you mean VAX/VMS!!!!
HG> systems-level code in it *without* regard for a compiler's run-time
HG> support. The only other language for which this is true is MACRO-32.
HG> C lets you do most of it, but you have to be *very* careful (and there
HG> are no JSBs, no macros that will elevate IPL for you and acquire
HG> spinlocks, etc.).
These machine instruction level dependencies of VAX/VMS are fundamentally
part of when and where VMS was originally developed. One could also argue
that such instruction level dependencies shouldn't be part of the more
generic operating system that Alpha/VMS will end up being, and hence the
need for compiler support for mechanisms like JSB linkage isn't or will not
always be necessary. I suspect that in the first go around, reworking
things at this level wasn't consistent with the primary business goal of
getting a reliable functional implementation to ship to customers as soon
as possible. We have heard more than rumors that the device driver
architecture is being reworked to allow device drivers to be written in C,
hence probably avoiding the need for the JSB linkage mechanisms that we
all know and love :-). The claim is that we should try to avoid writing
device drivers for Alpha/VMS V1.0 since they will have to be reworked when
this new I/O subsystem architecture is available.
HG> The problem with DEC preaching C for Alpha is that that means you
HG> *cannot* write code for VAX VMS that will compile without modification
HG> on Alpha VMS, since any calls to system routines (the EXE$ routines,
HG> etc.) have to be done via JSB, which C doesn't support. The only
HG> thing I've found that BLISS lacks is direct support for JMPs
HG> (though the compiler can be fooled into producing them).
First this only applies to system/kernel level code, User mode stuff
typically as no such dependencies. Even though the readers of this group
(myself included) like to hack in the realm of system code, 99+% of all
code running in VMS really is not affected by these implications.
Well, I also suspect that there really is one ultimate goal (for both us
customers and Digital), that there be ONE VMS operating system, and when
the Alpha/VMS is eventually updated to include all of the VAX/VMS
extensions beyond the VAX/VMS V5.4 reference, and is BACK-PORTED to the
VAX, we might end up with a completely uniform environment. We will have
to bear the pain of this transition though.
Personally, I'm looking forward to learning all about the Alpha
architecture, and how to deal with programming in the realm of the new VMS
kernel environment. Whether programming in C or BLISS, I expect that the
significance of JSB linkage will be diminishing over time.
--
Mark Pizzolato - INFO COMM Computer Consulting, Redwood City, Ca
PHONE: (415)369-9366 UUCP: decwrl!infopiz!mark or uunet!lupine!infopiz!mark
DOMAIN: ma...@infocomm.com
j...@cmkrnl.com
JH>
JH> A = .A + 1;
JH>
JH> The . should be required on both sides of the =, or on neither. This
JH> is completely opposite to *every* other language I've worked with --
JH> INCLUDING Macro.
HG> Well, the dot notation *always* throws people off when they first
HG> start using it (it did me). But once you think about it, it all makes
HG> sense. Variable names in BLISS *always* refer to the *address* of the
HG> data, not the data itself.
Not when they're on the left side of an equal sigh, they don't.
HG> The "." is used to fetch the value stored
HG> at that address. If you wrote
HG>
HG> A = A + 1;
HG>
HG> you'd be taking the address A represents (say 200) and incrementing by
HG> one, storing it back at 200. To increment the value stored at address
HG> 200, the "." is used to fetch that value.
I understand that. What I am objecting to here is that the semantics magically
change on the left side of the assignment operator. To continue this example,
"increment the value stored at location A" should be written as
A = A + 1;
or
.A = .A + 1;
but to require it to be written as
A = .A + 1;
is to completely blow away the claim that "Bliss has no special cases". If
that were true, this last satement would change the value of the symbol A!
of course, if we want to store our result four bytes beyond the address
represented by the symbol A, we *do* use a period on the left side:
.(A+4) = .A + 1;
Like I said... no special cases? Hah!
HG> BLISS is an expression language. There are no statements; everything
HG> has a value.
Yes. Even the looping constructs end up generating values. But while this is
an "elegantly" consistent design (see the APL langauge for an example of just
where *that* can get you), I have yet to see that it provides any practical
advantage.
HG> You can choose to ignore that value, but everything has
HG> one. This means that the left side of the expression above could have
HG> been any sequence that generates a valid address. For example (and
HG> I must admit that this starts getting a little confusing until you
HG> think about it), you could write:
HG>
HG> B = A; !Store the address A (200) at B (204)
HG> .B = .A + 1; !Increment value at A and store back in A
HG>
HG> The value of ".B" is the address of A, so .A+1 is stored back in A.
HG> This provides for some very flexible programming, though you must be
HG> careful (and document stuff like that).
Or in C you can say
long *b, a, c; /* b is a pointer to long, ie *b is a long;
a and c are longs */
b = &a; /* store the address of A at B */
*b = a + 1; /* increment value at A and store back in A */
but in a plain old everyday Fortran-ish assignment statement,
c = a + 1;
references to "ordinary" variables on both sides of the = look the same.
The big advantage of C, of course, is that if you forget and try to say
(with the above declarations in effect)
b = a + 1;
or
*b = *a + 1;
it won't let you! As well it shouldn't. (You can of course override type
checking with the cast operator, but that tells anyone reading the code to
read carefully, as something funny is going on.)
JH> Re the problems with structure defs in Bliss, someone told me "yeah,
JH> but you can use SDL for structure definitions", to which I replied, "I
JH> rest my case". If the language needs another software package to build
JH> data definitions for it, then the language is broken!
Now, new things:
--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru, VMSnet (DECUS uucp) Working Group, and
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG
Internet: j...@cmkrnl.com, hanr...@eisner.decus.org, or j...@crash.cts.com
Uucp: ...{crash,eisner,uunet}!cmkrnl!jeh
j...@cmkrnl.com
JH> And it is utterly ludicrous to have to write "increment A by one" as
JH>
JH> A = .A + 1;
JH>
JH> The . should be required on both sides of the =, or on neither. This
JH> is completely opposite to *every* other language I've worked with --
JH> INCLUDING Macro.
HG> Well, the dot notation *always* throws people off when they first
HG> start using it (it did me). But once you think about it, it all makes
HG> sense. Variable names in BLISS *always* refer to the *address* of the
HG> data, not the data itself.
Not when they're on the left side of an equal sigh, they don't. And that's
the problem: Bliss is inconsistent in this area. The "." would be fine,
but Bliss uses it inconsistently.
HG> The "." is used to fetch the value stored
HG> at that address. If you wrote
HG>
HG> A = A + 1;
HG>
HG> you'd be taking the address A represents (say 200) and incrementing by
HG> one, storing it back at 200. To increment the value stored at address
HG> 200, the "." is used to fetch that value.
I understand that. What I am objecting to here is that the semantics magically
change on the left side of the assignment operator. To continue this example,
"increment the value stored at location A" should be written as
A = A + 1;
or
.A = .A + 1;
but to require it to be written as
A = .A + 1;
is to completely blow away the claim that "Bliss has no special cases". If
that were true, this last statement would change the value of the symbol A!
HG> If you've ever seen the source to Matt Madison's MX, you'll know just
HG> what you can do with BLISS macros! 8-)
I have written some damned obscure macros in MACRO in my time... things that
generated itemlist3-itemlists in one psect, allocated buffer space in another
psect, and generated code to format and print the returned data in yet another
psect. Fun to write, but very difficult for anyone else to pick up and
understand.
If Bliss allows even more complex things, I'm not sure that that's an advantage.
I used to use Macros all the time to generate and initialize very complex sets
of data structures with interlocking pointers. Only trouble is, unless you
have a complete description of what's going on the comments, the only way
someone is going to figure out what the macro does is to expand it with full
expansion listings and tediously trace through all of the .psect changes.
HG> The *biggest* reason I prefer BLISS to C is that, with BLISS, you know
hg> exactly what you're getting: whatever you tell the compiler to
hg> generate. BLISS has no run-time support, so you never have to worry
hg> about the compiler generating a call to an external BLISS run-time
hg> routine. This is invaluable when trying to write privileged
hg> code---with C, you have to make sure you don't make any calls to
hg> built-in functions when running in kernel mode (depending on what you
hg> call) or at elevated IPL (since you *will* page fault). With BLISS,
hg> you never have to worry about external calls generated by the compiler
hg> *because it doesn't make any*! The *only* way an external call is
hg> made is if you call one of the system service or a VMS run-time
hg> library routine (or another external module). The compiler doesn't
hg> build in calls to its own run-time library because there isn't one.
As Mark has pointed out, the idea that VAX C builds in lots of calls to its RTL
"behind the programmer's back" is a myth. If you're worried about accidentally
calling a C RTL routine yourself, the answer is simple: Don't point the linker
at the C run-time library.
hg> And BLISS is a GOTO-less language! 8-)
This isn't an advantage either. It's true that, in most cases, eliminating
GOTOs makes for easier-to-read code. It is also true that absolutely requiring
that *no* GOTOs be used sometimes necessitates the use of *very* convoluted
code.
Fortunately, Bliss does have a GOTO in disguise. I forget its name, but it's
similar to C's 'break' statement. You put it inside a compound statement, and
it goes to the end of the compound statement. You put a label on the
*beginning* of the compound statement and reference this in the "un-goto"
statement. ("leave"? Something like that.) This allows you to easily exit
from a nest of compound statements under an exception condition, for instance.
But "GOTO-less"? Hah!
Eric Thomas, SUNET
> Do you mean "program in BLISS to protect yourself from machine
>changes" as in machine changes will be easier, or as in there is no
>BLISS for other machines so you will never have to port your code. My
>feeling was always the latter, and it seems to have failed like garlic
>keeping away vampires.
Come on... When you write a VMS device driver for the Schunkfus III magnetic
badge control system, what are the chances of you ever being able to port that
code to another machine, even assuming you had the need to do so some day?
Let's face it, system internals are not portable to other operating systems, no
matter the programming language. I don't think Hunter ever advocated the use of
BLISS as a general-purpose language, but rather stressed its usefulness for
systems programming - something intrinsically not portable, where what matters
is the amount of time you have to invest to get a working, and above all
reliable (bug -> system crash) solution.
> Sounds like a good decision. Proprietary code costs money to maintain,
I'm not quite sure I understand. Are you saying that BLISS costs more money to
maintain than a C compiler with the delicate extensions that would be required
to make systems programming possible, just because BLISS is proprietary? That
doesn't make sense to me: when you develop a proprietary solution and don't
have to worry about supporting other machines, you can tune it much better to
whatever it is you designed it for. In other words, one would expect BLISS to
be intrinsically adapted to systems programming under VMS and require
absolutely no special extensions - unlike C.
Eric
goath...@wkuvx1.bitnet
> In article <1992Apr20....@wkuvx1.bitnet>, goath...@wkuvx1.bitnet writes:
> JH> Also re type checking, if I (in C) define ucbptr as a pointer to a
> JH> struct of type ucb, lo and behold the compiler will not let me move
> JH> anything that ISN'T a pointer to a ucb into that field. Bliss just
> JH> doesn't care and will gladly let you shoot yourself in the foot just
> JH> as easily as Macro will.
>
> I generally agree with this advantage of C. C is simply a "higher" level
> language than BLISS is.
>
> HG> The *biggest* reason I prefer BLISS to C is that, with BLISS, you know
> HG> exactly what you're getting: whatever you tell the compiler to
[...]
> Actually, the only call to an external runtime routine that I've ever seen
> C generate is the "magic" it does to build the "main(argc, argv)" argument
> list which it ONLY does for the special case function/procedure "main".
> I've got lots of C programs that were never linked with any C runtime
> library at all. They simply didn't use anything having to do with c style
> strings, and/or I/O.
>
Again, true, but this is *only* if you don't use any C functions.
When people learn C, they almost always use C functions, which makes
it harder to leave them out when you need to.
> HG> This gets back to the heart of this discussion: BLISS *is* a better
> HG> systems programming language under VMS than C because you can write
>
> Lets qualify that a little ... you mean VAX/VMS!!!!
>
Let's qualify is this way: I mean VMS for the forseeable future.
There is, apparently, still a disctinction between CALLx entry points
and JSB entry points in Alpha.
[...]
> These machine instruction level dependencies of VAX/VMS are fundamentally
> part of when and where VMS was originally developed. One could also argue
> that such instruction level dependencies shouldn't be part of the more
> generic operating system that Alpha/VMS will end up being, and hence the
> need for compiler support for mechanisms like JSB linkage isn't or will not
> always be necessary.
Could be. It's certainly true that Alpha VMS has to support them in
some way because most of the code hasn't even been rewritten, just
recompiled. I suspect that you're right: as time goes by, such
differences will disappear. But that still doesn't help much *now*.
> I suspect that in the first go around, reworking
> things at this level wasn't consistent with the primary business goal of
> getting a reliable functional implementation to ship to customers as soon
> as possible.
True.
> We have heard more than rumors that the device driver
> architecture is being reworked to allow device drivers to be written in C,
> hence probably avoiding the need for the JSB linkage mechanisms that we
> all know and love :-). The claim is that we should try to avoid writing
> device drivers for Alpha/VMS V1.0 since they will have to be reworked when
> this new I/O subsystem architecture is available.
>
Sounds like we'd probably be better off not doing *anything* will
Alpha VMS v1.0. Alpha sounds great; Alpha VMS v1.0 sounds like
something you probably want to avoid if you're writing systems-level
code or OS hooks.
> HG> The problem with DEC preaching C for Alpha is that that means you
> HG> *cannot* write code for VAX VMS that will compile without modification
> HG> on Alpha VMS, since any calls to system routines (the EXE$ routines,
> HG> etc.) have to be done via JSB, which C doesn't support. The only
> HG> thing I've found that BLISS lacks is direct support for JMPs
> HG> (though the compiler can be fooled into producing them).
>
> First this only applies to system/kernel level code, User mode stuff
> typically as no such dependencies. Even though the readers of this group
> (myself included) like to hack in the realm of system code, 99+% of all
> code running in VMS really is not affected by these implications.
>
Again, true. Also, as I mentioned in another post: if I'm writing an
application that has some use outside of VMS, I'd use C. But 99% of
what I do is so VMS-specific, there's no way you could use it under
any other OS. For the systems stuff I do, BLISS just works better.
[...]
> Personally, I'm looking forward to learning all about the Alpha
> architecture, and how to deal with programming in the realm of the new VMS
> kernel environment. Whether programming in C or BLISS, I expect that the
> significance of JSB linkage will be diminishing over time.
>
Yes, I think you're right. While I personally prefer BLISS (have I
been to blatant about that? 8-) ), the *main* issue here is that
VAX C doesn't support things like JSB, which are required for writing
under VAX/VMS. If DEC would release VAX C v3.3 with support for JSBs,
real macros, etc., I wouldn't have as much problem with their touting
C for Alpha. Know what I mean?
goath...@wkuvx1.bitnet
> Disclaimer: I never wrote any code in BLISS :-)
>
> In my opinion, the main problem with BLISS is that you have to buy it. We don't
> have money to buy a DEC-specific language that doesn't compile on unix
> playstations -> no BLISS. It is pretty difficult to justify the purchase of
> that kind of compiler when you don't HAVE to write bunches of system codes as
> part of whatever the machine was bought for. Unless, of course, you get it free
> from some higher education consortium deal.
>
also true that BLISS is expensive. That's why I wish DEC would bundle
it with VMS, instead of MACRO. Or establish now that they plan to
support MACRO as an Alpha programming language (not just as a
transitional tool).
The company Ed and I used to work for purchased BLISS right before I left.
At the time, we were looking for something to try to wean the products
from their dependency on MACRO-32. We successfully argued that BLISS
was the only real option. It was a tough sell on people who still
used BASIC as the primary high-level language for all of their
products. (MACRO and BASIC---it was always very embarassing to get
calls from customers saying, "Yeah, XXXX is printing this BASIC
error!") Of course, after we left, they continued to write in BASIC
and MACRO (and still are, as far as I know).
>>HG> Hmmm. Valid complaints about BLISS, but I find it to be a much more
>>HG> logical language than C. It has many of the same powerful features
>>HG> (multiple assignments in one expression) but isn't nearly as cryptic.
>
> From the small amount of BLISS code I have seen, it has a very significant
> advantage over C: it wasn't designed by someone who looked at his keyboard,
> rubbed his hands in gleeful anticipation, and said "Now, let's see which of the
> symbols I haven't found a use for yet..." :-) While this is basically
> irrelevant to US programmers, over here it means that my code doesn't look
> like:
>
Good point! I've tried to refrain from my basic complaints with UNIX
and C....
>>JH> otoh, there are lots of nice things re string handling in the C RTL.
>>JH> And I've never found the problems to be that tough to overcome.
>
> That is one of my pet peeves. The C language and standard library do NOT have
> ANY support for STRINGS, ie things defined by an address, a length, and a
> maximum length for R/W strings. The C language has support for chunks of
[...]
> is, OBVIOUSLY, no way to tell sprintf that your buffer has only got 256 bytes
> and it shouldn't happily overlay whatever follows if, for any reason, there
> isn't enough space. Why should one want to do that? It prevents fun things like
> Internet worms ;-)
>
Well said!
>>BLISS's macro facility is more powerful than that of any other
>>language I've ever seen.
>
> C does not have a macro facility, that is one of its major drawbacks. Oh, it
> has a text-based pattern substitution facility, all right, but that simply
> doesn't cut it.
>
I was amazed when I first started learning C and found how primitive
the "macro" stuff was. I was used to MACRO macros....
> Concrete example #2: I want to write a macro that does something obfuscated,
> like generate 5 lines of code full of casts. But I want to do something
> different depending on the parameters - for instance, if the first one starts
> with a double quote, I want to append a "\n" to make unix-style file routines
> happy, whereas if it's the address of a buffer I want to use strcat instead.
> Then if the second and third arguments are the same, I need to do something
> specific. Well I end up with several macros which are almost, but not quite the
> same and which I have to keep in synch, and I have to remember the subtle
> differences in the names... If I make a mistake and use the wrong name, it will
> compile happily, but not do what I thought :-)
>
This is all very easy to do with BLISS macros. And, as Ed mentioned
in another post, the fact that you can have KEYWORD macros is a
blessing, because you don't *have* to remember the order of arguments
to system services and other routines.
>>The problem with DEC preaching C for Alpha is that that means you
>>*cannot* write code for VAX VMS that will compile without modification
>>on Alpha VMS, since any calls to system routines (the EXE$ routines,
>>etc.) have to be done via JSB, which C doesn't support.
>
> Maybe it just means DEC doesn't want you to write Alpha device drivers? :-)
>
Could be. While at my old company, I often wondered if DEC didn't so
some low-level OS things just to make it difficult for companies like
that. 8-)
goath...@wkuvx1.bitnet
> BLISS is CONSISTENT with treating EVERYTHING as an ADDRESS, whereas with
> C do I need &a, a, *a, etc. Also, talk about confusing, if I have a
> structure in BLISS, it is ALWAYS .pcb [PCB$L_PID], whereas in C, is it:
>
> pcb.PCB$L_PID OR pcb->PCB$L_PID ?????
>
Even when I think I understand this part of C, I get confused....
> Plus, zero terminate strings are highly inefficient! Counted strings are
> VERY efficient. BLISS lends itself to counted strings.
>
Yeah; zero-terminated strings let you copy them with the simplest of
loops, but that's about all they're good for. I think it's horrible
the way you have to count all the bytes everytime you want to find the
length of a string (even constant strings).
MIL...@tgv.com
Oh my. Well, I have to jump in on this one. I spent three years at CMU
writing code in BLISS. Before that, I worked on a real-time Unix kernel
which was writen in C++. I've spent the past year writing system code in
both C and MACRO.
First of all, "A = .A + 1" is not a special case. The binary operator, "="
takes two operands and returns a boolean value. The two operands are
an "lvalue" and an "rvalue", two differant animals. This will only seem
inconsistant to people who are used to C.
The construct is fine; the world is screwed up.
Secondly, you *can* write device drivers in C if you do the driver table
stuff in MACRO. I've done it. In fact, MultiNet is really just one huge
device driver. We bypass the JSB problem by writing little in-line
assembly statements (using GCC, the "other" compiler). I always worry
a bit about C, though. I don't always trust the code it produces. Still,
if you don't link with VAXCRTL, and you're careful about volatile locations,
everything usually works out.
Cool things about BLISS:
The macro facility
Built-in access to the stack, including AP, FP, and
the condition handler slot.
Optional type-checking
Data structures with access methods.
%ASCID declarations.
I don't know why everyone complains about the dot derefs. C has the
same thing in the & operator. Why should I have to use a special
character to get the adress of something? And BLISS is consistant.
Labels always return the address of a data area. Jamie pointed out
that this is inconsistant in the case of the assignment expression,
but it isn't really. The lvalue requires the address of the area to
store the result of the expression, and that's what we pass. C, on
the other hand returns either an address or data, depending on what
type of structure you're using (long, char, struct, enum, array, etc...)
That can get really annoying when you're developing code and switching
between arrays and structs to implement a piece of data.
Another cool thing about BLISS:
Linkage declarations.
PSECT control in data declarations.
BLISS is *not* a lower-level language than C. It is both higher level
*and* lower level. BLISS has all the language constructs that C has
and more (ie. structure access methods). It also provides direct access
to the metal. You can program at any level you like.
The problem with C, in my mind, is that the VAXCRTL is so closely
associated with it. The C rtl was writen for Unix programmers who,
by and large, are lazy. The string functions are a perfect example.
Now, in a lot of cases the inefficiency of the rtl is perfectly
acceptable. It can save a lot of programming time and effort.
But from what I've seen I would guess that C programmers come to
rely on them to the exclusion of more reasonable methods. I get
so discusted when I see VMS networking code using select() and
fork(). Ugh! Ack! Phft! Bad! No cookie!
BLISS does have a GOTO of sorts. I think the LEAVE contruct will
optionally take a location to jump to.
Even more cool stuff about BLISS:
Comments.
In addition to the standard comment construct you can also comment
out a line by putting a "!" at the begining. In C you have to change
the begining and the end of the line, which can be a hassle and can look
ugly too. I don't remember whether BLISS allowed nested comments or
not. C doesn't, but you get around that by doing "#ifdef NOTDEF"s.
Whatelse... Ah, bit-field manipulation that blows C away.
Explicit address mode specification.
Pre-compiled "include" files.
Blocks (BEGIN/END) are expressions. Very useful too.
You don't need explicit return statements if you run off the end of
a routine.
Built-in condition handling support.
The UNDECLARE directive, for those without self-restraint.
Easy use of variable length function argument lists.
Much more powerful loop and select (case) constructs.
Built-in utilities (ch$copy, CH$FILL, etc...) don't require an
extra stack frame, like they do with the CRTL.
And so on...
These are all facilities that are useful in an application-level
environment as well as at the system code level.
Personally, I like C. If there's something I can't do in C, I do it in
MACRO. I use C because BLISS is so obscure. Maybe someday everyone will
see the light and BLISS will be the language of choice on all platforms.
Yeah, and monkeys might fly out of my butt.
-bruce
----------------------------------------------------------------------------
Bruce R'. Miller, MIL...@TGV.COM (408) 427-4366 in Santa Cruz CA
"And through the wire, we can talk..." - PG
Hunter Goatley, WKU
>
>Oh my. Well, I have to jump in on this one. I spent three years at CMU
>writing code in BLISS. Before that, I worked on a real-time Unix kernel
>which was writen in C++. I've spent the past year writing system code in
>both C and MACRO.
>
>
>These are all facilities that are useful in an application-level
>environment as well as at the system code level.
>
>Personally, I like C. If there's something I can't do in C, I do it in
>MACRO. I use C because BLISS is so obscure. Maybe someday everyone will
>see the light and BLISS will be the language of choice on all platforms.
>
Well, for now, I'll settle for BLISS on Alpha. That's all I want, really.
The assurance that I'm safe if I do that. As I've said a number of times
that I write code that is so VMS-specific it can't be ported anyway. So
let me do it in BLISS and know it'll work under Alpha and I'll be happy
enough. IF/when I have to learn the other OS, I'll start using C.
>Yeah, and monkeys might fly out of my butt.
>
Hey, this'd kill 'em at VAX MAGIC, wouldn't it?!?! 8-)
Brian Thomson
>In article <1992Apr20....@wkuvx1.bitnet>, ed_he...@npd.novell.com writes:
>> Plus, zero terminate strings are highly inefficient! Counted strings are
>> VERY efficient. BLISS lends itself to counted strings.
>>
>Yeah; zero-terminated strings let you copy them with the simplest of
>loops, but that's about all they're good for. I think it's horrible
>the way you have to count all the bytes everytime you want to find the
>length of a string (even constant strings).
Interestingly, C's grandfather BCPL had counted strings.
Dennis Ritchie must have not agreed that they were so wonderful.
--
Brian Thomson, CSRI Univ. of Toronto
utcsri!uthub!thomson, tho...@hub.toronto.edu
david carlton
>HG> Variable names in BLISS *always* refer to the *address* of the
>HG> data, not the data itself.
> Not when they're on the left side of an equal sign, they don't.
Sure they do. The = operator is a function taking an address and a
value and sets the location specified by that address equal to that
value. Admittedly, calling it something like := might have been a bit
better, to emphasize that it is an assignment operator rather than an
equality one. It wouldn't make any sense to require the . on both
sides - for example, assume .A is equal to 3. Then
.A = .A + 1
would pass the values 3 and 4 to the assignment operator, and it would
have no idea where to store the value. Similarly, if you had the . on
neither side, i.e. incrementing by writing
A = A + 1
then you would have to somehow know that you should dereference the
right-hand A but not the right-hand 1, and if you wanted to set the
value of A to be what would in C's notation be &A + 1, you would have
to add an explicit "address-of" operator. So BLISS's way of handling
assignment is really the only way to do that while still having
assignment be a function.
david carlton
car...@husc.harvard.edu
Go on, EMOTE! I was RAISED on thought balloons!!
Phil Tait, (602) 231-7104
> Yeah; zero-terminated strings let you copy them with the simplest of
> loops, but that's about all they're good for. I think it's horrible
> the way you have to count all the bytes everytime you want to find the
> length of a string (even constant strings).
Well, for constant strings, something like:
char string[] = "some unchanging stuff";
#define STRING_LEN (sizeof string - 1)
might not be _too_ horrible. :-)
--
Philip J. Tait Allied-Signal Aerospace, Garrett Engine Division, Phoenix, Az
(602) 231-7104 Aeronet: GED::B12635 FQDN: b12...@ged.gedlab.allied.com
Preston Briggs
>Interestingly, C's grandfather BCPL had counted strings.
>Dennis Ritchie must have not agreed that they were so wonderful.
If using counted strings, how much space do we allocate for the count?
Well, it depends doesn't it?
Zero-terminated strings are just a way of representing string
constants. The rest of the language has no real notion of strings.
Counted strings are a higher-level concept -- a data structure!
You're of course free (even encouraged) to define all sorts of data
structures.
Preston Briggs
j...@cmkrnl.com
> advantage over C: it wasn't designed by someone who looked at his keyboard,
> rubbed his hands in gleeful anticipation, and said "Now, let's see which of the
> symbols I haven't found a use for yet..." :-)
This same reverence for "terseness" at the expense of readability infects
everything associated with Unix, it seems.
But for most of the symbols, you can do things like
#define BEGIN {
#define END }
if (whatever) BEGIN
...
END
and you can also define (mnemonic!) names for the lesser-used logical and
bitwise operators.
>>JH> otoh, there are lots of nice things re string handling in the C RTL.
>>JH> And I've never found the problems to be that tough to overcome.
>
> That is one of my pet peeves. The C language and standard library do NOT have
> ANY support for STRINGS, ie things defined by an address, a length, and a
> maximum length for R/W strings.
Well, guess what -- neither does Bliss. I've always wished that VMS
descriptors included fields for the current *and* the maximum length. But
then they wouldn't fit neatly in a quadword.
> I have had to maintain a C application totalling
> something like 1M of code, and most of the problems arose from sprintf()'s into
> buffers that happened to be too small for some input value.
But you're right, and sticking to the VMS RTL with dynamically-allocated
output strings is a good way to avoid such problems.
(I always chuckle at the folks who, seemingly every year, ask that VMS system
services that return strings be allowed to return *dynamic* strings. Fact is,
for every system service that returns a string, there's an RTL routine that
calls it and returns a dynamic string. The system services are there for use
in environments where you can't use the RTL safely.)
Peter da Silva
> symbols I haven't found a use for yet..." :-) While this is basically
> irrelevant to US programmers, over here it means that my code doesn't look
> like:
> Ainclude <stdio.h>
>
> if (aOi++E X= 3) a
> printf("Error with element %d.En", i);
> flags != ERR_IN_ELEMENT;
> a
Get an ISO8859 terminal instead of that ISO646 one. Total cost, $400, and
you get to handle other European languages as easily as Swedish.
> That is one of my pet peeves. The C language and standard library do NOT have
> ANY support for STRINGS, ie things defined by an address, a length, and a
> maximum length for R/W strings.
True. So write the routines once and have done with it.
> buffers that happened to be too small for some input value. What can you do?
Write "snprintf". Once.
> C does not have a macro facility, that is one of its major drawbacks.
You want to use real macros, use m4.
--
Peter da Silva `-_-'
Programmer, network firefighter, thrillseeker 'U`
Ferranti International Controls Corporation Have you hugged
Sugar Land, TX 77487-5012 +1 713 274 5180 your wolf today?
Peter da Silva
> length of a string (even constant strings).
sizeof "this is a string"
works fine.
George J. Carrette
> Personally, I like C. If there's something I can't do in C, I do it in
> MACRO. I use C because BLISS is so obscure. Maybe someday everyone will
> see the light and BLISS will be the language of choice on all platforms.
>
Personally, I think DEC really blew it in the BLISS area. Here they
had, circa 1976, BLISS, as a common language on their mainframe, TOPS-20
(36-bit) and on their 16-bit micro, the PDP-11, and also on their brand new
machine, the VAX.
You could READ in K&R about indications that maybe C worked in a 36-bit
environment, 32-bit, and 16-bit, environments on different operating
systems, but if *fact*, at any one time, good luck trying to find
consistent concrete examples of this. Certainly not an available product!
Cross compiling BLISS from the PDP-10 (TOPS-20) to the PDP-11 was a
typical working environment at the time.
But then, did somebody decide that selling the BLISS compiler for the VAX
would be a great profit-center item?
I remember circa 1980 at MIT that VAX LISP DEVELOPMENT we were doing
(for DIGITAL! on a DIGITAL donated machine!) was severely limited by
our inability to obtain the latest BLISS compiler without coming up
with $35k.
And then, when DEC came out with their PC, the Rainbow, who decided
that you would need to buy a $150k VAX system to cross compile from
the obscure language PASCAL in order to develop software for the thing?
Did anyone at DEC ever try to port the pdp-11 bliss code generator
to produce 8-bit 8080 code, or 8086 or 16-bit 80286 code?
Who killed that project?
> Yeah, and monkeys might fly out of my butt.
>
How about gerbils?
-gjc
Eric Thomas, SUNET
>If using counted strings, how much space do we allocate for the count?
On a VAX it would be 4 bytes, why?
>Zero-terminated strings are just a way of representing string
>constants. The rest of the language has no real notion of strings.
>Counted strings are a higher-level concept -- a data structure!
>You're of course free (even encouraged) to define all sorts of data
>structures.
Well I have done just that - written a string manipulation library (with PASCAL
rather than C, but it makes no difference). One major pain in the butt becomes,
precisely, the use of constants in source code. If I code something like 'Total
number of occurences: ' in my source program, I get an object which I cannot
use directly with my routines. Of course the first thing I did was to write a
trivial function taking a PASCAL string as input and returning a structured
string, and it does solve the problem, except that it's a pain to type
duh('text') all the time rather than just the text, and it wastes CPU time. You
waste CPU time again by being unable to take advantage of in-line built-in
primitives, such as comparison to a constant; where a CMPL/CMPC3 sequence would
have been coded had the compiler supported this type of strings, you get a call
to the duh function and then a call to a comparison routine.
So the bottom line is that, while you are not "stuck" with the string system
provided by your compiler+library, if that string system is inefficient there
may be no way you can ever reach the efficiency of other compilers whose only
virtue was to choose an efficient representation, because going against your
compiler's design will cost you a lot of calling overhead.
Eric
Hunter Goatley, WKU
>
>In article <1992Apr20....@sunic.sunet.se>, er...@sejnet.sunet.se
>(Eric Thomas, SUNET) writes:
>> From the small amount of BLISS code I have seen, it has a very significant
>> advantage over C: it wasn't designed by someone who looked at his keyboard,
>> rubbed his hands in gleeful anticipation, and said "Now, let's see which of
> the
>
>everything associated with Unix, it seems.
>
>But for most of the symbols, you can do things like
>
> #define BEGIN {
> #define END }
>
> if (whatever) BEGIN
> ...
> END
>
>and you can also define (mnemonic!) names for the lesser-used logical and
>bitwise operators.
>
But then other C programmers have a very difficult time reading it. You've
become "non-standard", if there is such a thing with C.
>> That is one of my pet peeves. The C language and standard library do NOT have
>> ANY support for STRINGS, ie things defined by an address, a length, and a
>> maximum length for R/W strings.
>
>Well, guess what -- neither does Bliss. I've always wished that VMS
>descriptors included fields for the current *and* the maximum length. But
>then they wouldn't fit neatly in a quadword.
>
Of course, you can use varying length string descriptors, like PL/1 uses.
At least with BLISS, you *know* you don't have string support beyond what
CH$MOVE, CH$COMPARE, etc., give you. C's support can be misleading,
especially if you aren't familiar with how C handles strings.
>(I always chuckle at the folks who, seemingly every year, ask that VMS system
>services that return strings be allowed to return *dynamic* strings. Fact is,
>for every system service that returns a string, there's an RTL routine that
>calls it and returns a dynamic string. The system services are there for use
>in environments where you can't use the RTL safely.)
>
I always kringe at the people who write in MACRO-32 and call the RTL
versions not so they can use dynamic strings, but just because they
don't know that they correspond to system services. Not very good when
you're writing production code that should be efficient (and I've seen it
done in code that *claimed* to be efficient).
MIL...@tgv.com
Here's my favorite example of C obfuscation. This is David Kashtan in rare
form. I found it while poking around in the bowels of David's NFS server
code. Maybe he was on drugs that day...
Routine = (int (*)())(*(int *)((caddr_t)Request_ListP + 20));
/*
* Call it
*/
Next_Request_Addr = (struct IOCONTEXT *) (*Routine)();
if (Next_Request_Addr) {
Next_Request = *Next_Request_Addr;
Mount_State_Addr = Next_Request_Addr->Mount_State;
Mount_State = *(Next_Request_Addr->Mount_State);
Next_Request.Mount_State = &Mount_State;
}
/*
* Also get the driver status flags...
*/
if (** (long **) ((caddr_t) Request_ListP + 32)) {
Reload_Uid_Mapping = 1;
** (long **) ((caddr_t) Request_ListP + 32) = 0;
}
Now do you see what I have to contend with? :-)
Ian Dall
In article <1992Apr21....@wkuvx1.bitnet>, goath...@wkuvx1.bitnet writes:
>
> > Plus, zero terminate strings are highly inefficient! Counted strings are
> > VERY efficient. BLISS lends itself to counted strings.
> >
> Yeah; zero-terminated strings let you copy them with the simplest of
> loops, but that's about all they're good for. I think it's horrible
> the way you have to count all the bytes everytime you want to find the
> length of a string (even constant strings).
You don't have to count string lengths for constant strings in any C
compiler I have seen. I don't know for sure about the letter of the
standard.
sizeof("abc") - 1
is 3.
You can easilly write macros and functions for manipulating counted
strings. For example:
#define INI_STRING(x) {sizeof(x) - 1, x}
#define STRLEN(x) (x.length)
#define STRPTR(x) (x.ptr)
typedef struct {int length; char *ptr;} string;
string s = INI_STRING("The Quick Brown Fox Jumped Over the Lazy Dog's Back");
main()
{
printf("String size of:\n \"%s\"\nis %d\n ", STRPTR(s), STRLEN(s) );
}
--
Ian Dall I'm not into isms, but hedonism is the most
harmless I can think of. -- Phillip Adams
ACSnet: da...@hfrd.dsto.oz
internet: da...@hfrd.dsto.oz.au
Hunter Goatley, WKU
>
>> Yeah; zero-terminated strings let you copy them with the simplest of
>> loops, but that's about all they're good for. I think it's horrible
>> the way you have to count all the bytes everytime you want to find the
>> length of a string (even constant strings).
>
>You don't have to count string lengths for constant strings in any C
>compiler I have seen. I don't know for sure about the letter of the
>standard.
>
that an extra LOCC isn't so bad---*if* that's what the compiler generates,
you're right: it's not *too* bad. But it still adds some inefficiency
to code, since LOCC is a relatively expensive intruction.
Eric Thomas, SUNET
>Get an ISO8859 terminal instead of that ISO646 one. Total cost, $400, and
>you get to handle other European languages as easily as Swedish.
First, a small correction: the total cost is $400/terminal, which can amount to
quite a lot of money if you have a lot of terminals as we do. I have a VT340
anyway, I believe it supports that codepage.
But none of this would solve the problem since the reason people have a Swedish
terminal is so that they can exchange mail in Swedish with other Swedish
speaking people. It is a sad fact of life that, nowadays, many SMTP's (mostly
on PC's) are still 7-bits-only and that most people use the 7-bits ASCII
encoding of national characters. That is, the mail I get uses brackets, braces
et al to represent national characters. What I really need, and what ALL
terminal manufacturers have missed, is a simple switch that lets you select a
font for what is shown on the display: push it to the left and you get US
symbols suitable for programming, to the right you get swedish letters. I have
such a switch on my ancient IBM 3278-2, unfortunately it is not used to switch
between US and swedish fonts but between ALL CAPS MODE FOR PEOPLE WHO LIKED
TERMINALS WITHOUT LOWER CASE BETTER and regular mixed-case mode :-) But if I
were able to change the PROM that implements it, it would be perfect. Again,
this has to affect the data currently on the screen, no the way new data from
the host is displayed: I want to switch back and forth if I watch a piece of
mail in Swedish with questions about a piece of C.
Now, I'll tell you how I solved this problem. We got a microVAX out of an
international grant, which came with a US terminal for system console. I stole
that terminal (which is only used for booting) and replaced it with a swedish
one. I use the US terminal to read C code. However I did not manage to do the
same for my IBM machine, and sending files over to the VAX every time just to
watch them is a royal pain.
>Write "snprintf". Once.
Sure. I could also write my own compiler, everything can be done. sprintf() is
not a trivial piece of work, one has to write code to format the various types
of floating point numbers and this code is not portable. If my code is not
going to be portable, there is no reason I should put up with C. Even if
snprintf() came with the C library, it would still be based on inefficient
ASCIZ strings. Hence my displeasure.
Eric
MIL...@tgv.com
>I sit corrected. I had forgotten about sizeof(). Someone else mentioned
>that an extra LOCC isn't so bad---*if* that's what the compiler generates,
>you're right: it's not *too* bad. But it still adds some inefficiency
>to code, since LOCC is a relatively expensive intruction.
What LOCC? What compiler *should* know the size of the statically allocated
data area used to store the string. I always thought of sizeof() as C's
version of BLISS's %ALLOCATION directive. I just checked it out on the
VAXC compiler and it does in fact generate a compile-time constant.
That reminds me of another cool BLISS directive: %CTCE
It evaluates to 1 if the expression you give it can be evaluated at
compile-time (as opposed to link-time or run-time). I actually found
a use for it once. I was so proud of myself for days and days afterwards...
Hunter Goatley, WKU
>
>>I sit corrected. I had forgotten about sizeof(). Someone else mentioned
>>that an extra LOCC isn't so bad---*if* that's what the compiler generates,
>>you're right: it's not *too* bad. But it still adds some inefficiency
>>to code, since LOCC is a relatively expensive intruction.
>
>What LOCC? What compiler *should* know the size of the statically allocated
>data area used to store the string. I always thought of sizeof() as C's
>version of BLISS's %ALLOCATION directive. I just checked it out on the
>VAXC compiler and it does in fact generate a compile-time constant.
>
was for non-constant strings when doing strlen(), which you have to do if
you haven't saved the length somewhere else.
It's pretty obvious that I've been working in BLISS for the last year and
*not* C....
>That reminds me of another cool BLISS directive: %CTCE
>
>It evaluates to 1 if the expression you give it can be evaluated at
>compile-time (as opposed to link-time or run-time). I actually found
>a use for it once. I was so proud of myself for days and days afterwards...
>
That's pretty good.
While I'm at it, I'd like to point out one of the nicest things I like
BLISS (at least under VAX VMS). You can generate listings that can be
be assembled by MACRO *WITHOUT MODIFICATION*. Very handy when you write
something in BLISS and want people who don't have BLISS to be able to
compile it themselves. (I distribute most of my BLISS programs with the
.MAR files too).
Too bad VAX C, once again, doesn't *quite* let you do that. It's really
very close to providing that capability, but it leaves out some things.
Peter da Silva
> string, and it does solve the problem, except that it's a pain to type
> duh('text') all the time rather than just the text, and it wastes CPU time.
So write a preprocessor that converts `text` into "\004\000text". Of course
it needs to properly adjust to hardware configuration. How about:
%{
#include <stdio.h>
#include <ctype.h>
#ifdef M_XENIX
#define UCHAR char
typedef int size_t;
#else
#include <sys/types.h>
#define UCHAR unsigned char
#endif
char buffer[BUFSIZ] = "";
%}
%%
`[^\n`]*` { strcat(buffer, yytext+1);
}
. { if(buffer[0]) {
outstr(buffer);
buffer[0] = 0;
}
ECHO;
}
\n { if(buffer[0]) {
outstr(buffer);
buffer[0] = 0;
}
ECHO;
}
%%
outstr(buffer)
char *buffer;
{
size_t len;
UCHAR *foo;
int i;
len = 0;
for(i = 0; buffer[i]; i++) {
len++;
switch(buffer[i]) {
case '\\':
if(strchr("abfnrt\\", buffer[i+1]))
i++;
else if(isdigit(buffer[i+1])) {
int j;
for(j = 0; j < 3; j++)
if(isdigit(buffer[i+1]))
i++;
else
break;
}
break;
case '`':
if(!buffer[i+1]) {
buffer[i] = 0;
i--;
len--;
}
break;
}
}
putchar('"');
/* Type punning! */
foo = &len;
for(i = 0; i < sizeof len; i++)
printf("\\%03o", foo[i]);
while(*buffer) {
switch(*buffer) {
case '"':
putchar('\\');
default:
putchar(*buffer);
}
buffer++;
}
putchar('"');
David P. Murphy
>VERY efficient. BLISS lends itself to counted strings.
>
"highly" inefficient? just how much CPU time do you think is consumed
by calculating the string length during the course of any application?
maybe .00001% or so . . . *not* a hot spot by any stretch of the imagination.
besides, there's the LOCC instruction to find the null byte for you,
so even the actual calculation can't be too slow.
ObTechNote: the 3B2 operating system has a machine instruction called STRCPY
which copies an asciz string to a separate buffer, but has no
equivalent to MOVC3, so copying a large number of binary bytes
takes places 4 bytes at a time. now *there*'s a hot spot!
ok
dpm
--
mur...@npri6.npri.com 602 Cameron St. Alexandria, VA 22314 (703) 683-9090
When every one is dead the Great Game is finished. Not before.
--- Hurree Babu, "Kim"
d...@zl2tnm.gen.nz
> I sit corrected. I had forgotten about sizeof(). Someone else mentioned
> that an extra LOCC isn't so bad---*if* that's what the compiler generates,
> you're right: it's not *too* bad. But it still adds some inefficiency
> to code, since LOCC is a relatively expensive intruction.
LOCC is also outside the "core" instruction set of the VAX architecture --
subset implementations mostly leave it out. Unfortunately, this includes
most (all?) of the CVAX (3xxx, 6xxx) line ... (not to mention mypoor lowly
VAXstation II 8-( )
Don Stokes, ZL2TNM (DS555) d...@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre d...@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand +64-4-495-5052
Frank J. Nagy:VAX Wizard&Loose Cannon
>subset implementations mostly leave it out. Unfortunately, this includes
>most (all?) of the CVAX (3xxx, 6xxx) line ... (not to mention mypoor lowly
>VAXstation II 8-( )
Not completely true. My KA630-AA CPU Module User's Guide (EK-KA630-UG-001)
states that the MicroVAX II CPU chip provides special microcode "hooks"
to aid the emulation of the character string instructions, except for
MOVC3 and MOVC5 (which are implemented on the chip).
However, the KA650 CPU Module Technical Manual (EK-KA650-UG-001) states
that the character string instructions MOVC3, MOVC5, CMPC3, CMPC5, LOCC,
SCANC, SKPC and SPANC are implemented in the chip's microcode and all
other character string instructions have a special microcode assistance
for emulation software.
So the situation changed from the MicroVAX II CPU chip to the MicroVAX 3000
CPU chip. I thought that the remaining 3000s, the 6000s and the 4000s
CPU chips implemented the same subset as the KA650 CPU.
= Dr. Frank J. Nagy "VAX Guru & Wizard, Loose Cannon"
= Fermilab Computing Division/Distributed Computing Dept/Special Projects Grp
= HEPnet/SPAN: FNDCD::NAGY (43123::NAGY) or FNAL::NAGY (43009::NAGY)
= Internet: NA...@FNAL.FNAL.GOV = BitNet: NAGY@FNAL
= USnail: Fermilab POB 500 MS/234 Batavia, IL 60510
Eric Thomas, SUNET
>LOCC is also outside the "core" instruction set of the VAX architecture --
>subset implementations mostly leave it out. Unfortunately, this includes
>most (all?) of the CVAX (3xxx, 6xxx) line ... (not to mention mypoor lowly
>VAXstation II 8-( )
True, and finally, LOCC operates on at most 64k. This means you really need a
loop of LOCC's, which admittedly will only run once most of the time, but still
has to be there, making the output longer and wasting CPU cycles. Ah, but I was
about to forget: "Nowadays, computers are fast and cheap". Hmm, when was it I
heard this dogma for the first time? 1982 if I am not mistaken. I guess K&R
were visionaries, and had predicted that computers would be and remain fast and
cheap for decades, thus making it legitimate to waste CPU cycles just so that
string manipulation could look particularly elegant in a particular language
('for (r = s1, w = s2; *w++ = *r++;);').
Eric
GAV...@vesta.sunquest.com
>Subject: BLISS vs. C: asciz strings are fine with me
Really this is degenerating into another religious war.
Descriptors come in varying types, each with its own
strengths and weaknesses. Just remember the following:
1. No matter whether the length is stored as a pre-counted
string or as a null-terminated string, most uses for
strings involve looping and doing something with all
elements of the string. Thus:
Get length of string
From 1 to end of string
do something with element i
end do
is just as efficient as:
While element[i] is not null
do something with element[i]
end do
While some would argue that comparing a[i] to \0 involves
one more lookup than comparing i to length, you'll note that
since you HAVE TO GET THAT LOCATION READ IN ANYWAY, caching
will optimize that away for you.
2. This religious war really has VERY LITTLE TO DO WITH C OR
BLISS since either allows you to define whatever-the-heck
structures you want to use. This discussion really has
drifted to "what is the default string storage type."
Whoop-de-do. The only language that has a default string
manipulation library and structure I go for is BASIC :-)
3. Some of you have gone so far as to blame VAXCRTL for BLISS
being better than C. Personally, I agree. In fact, all of
my code goes out of its way to avoid linking with VAXCRTL.
However, again, this is the mettle of the RTL, not the
language.
4. FINALLY, some of you have drifted off to discussing Alpha
and no BLISS on Alpha. While I agree here too, the original
subject of this inanely-long thread has been:
BLISS AND C, WHICH IS BETTER FOR VMS...
>>Plus, zero terminate strings are highly inefficient! Counted strings are
>>VERY efficient. BLISS lends itself to counted strings.
>>
>>ed_he...@npd.novell.com
>
>"highly" inefficient? just how much CPU time do you think is consumed
>by calculating the string length during the course of any application?
>maybe .00001% or so . . . *not* a hot spot by any stretch of the imagination.
>
>ObTechNote: the 3B2 operating system has a machine instruction called STRCPY
> which copies an asciz string to a separate buffer, but has no
> equivalent to MOVC3, so copying a large number of binary bytes
> takes places 4 bytes at a time. now *there*'s a hot spot!
>
Dave, it would probably be more efficient to clear the last byte
and use STRCPY. Once again, the issue of whether the length is
pre-stored or not is irrelevant...
>ok
>dpm
>--
>mur...@npri6.npri.com 602 Cameron St. Alexandria, VA 22314 (703) 683-9090
Ehud
--
Ehud Gavron (EG76)
gav...@vesta.sunquest.com
"The world bores you when you're cool."
Arne Vajhxj
> >subset implementations mostly leave it out. Unfortunately, this includes
> >most (all?) of the CVAX (3xxx, 6xxx) line ... (not to mention mypoor lowly
> >VAXstation II 8-( )
>
> states that the MicroVAX II CPU chip provides special microcode "hooks"
> to aid the emulation of the character string instructions, except for
> MOVC3 and MOVC5 (which are implemented on the chip).
>
> However, the KA650 CPU Module Technical Manual (EK-KA650-UG-001) states
> that the character string instructions MOVC3, MOVC5, CMPC3, CMPC5, LOCC,
> SCANC, SKPC and SPANC are implemented in the chip's microcode and all
> other character string instructions have a special microcode assistance
> for emulation software.
>
> So the situation changed from the MicroVAX II CPU chip to the MicroVAX 3000
> CPU chip. I thought that the remaining 3000s, the 6000s and the 4000s
> CPU chips implemented the same subset as the KA650 CPU.
Readers of INFO-VAX may remember, that I posted an instruction timing
program and collected results.
Here are the times for the LOCC instruction (ns for 10000 bytes):
MVAX3300 4476340
MVAX3400 4478316
MVAX3600 3826592
MVAX3900 2595048
MVAXII 31424986
VAX4200 1933768
VAX4300 2155600
VAX4500 1027908
VAX6300 3040964
VAX6400 2200260
VAX6600 858988
VAX780 4396876
VAX8350 3899428
VAX8600 1007804
VAX8650 671336
VAX8700 745972
VAX8800 646204
VAX9200 57000
VAX9400 45096
VAXS2000 33322804
VAXS3100-30 3918636
VAXS3100-38 3889768
VAXS3100-58 4612876
VAXS3100-76 2122200
VAXS3200 3917992
VAXS4000-60 1333856
We see, that LOCC is much faster on the VAX 3x00 than microVAX II, but not
quite as fast as the "old VAX'es" (8600,8650,8700,8800).
PS: Remember to adjust for machinepower (f.ex. MVUPS), when you compare
the numbers above.
Arne Vajhxj
Arne Vajhxj local DECNET: KO::ARNE
Computer Department PSI: PSI%238310013040::ARNE
Business School of Southern Denmark Internet: AR...@KO.HHS.DK
j...@cmkrnl.com
> In article <1992Apr25....@zl2tnm.gen.nz>, d...@zl2tnm.gen.nz writes...
>>LOCC is also outside the "core" instruction set of the VAX architecture --
>>subset implementations mostly leave it out. Unfortunately, this includes
>>most (all?) of the CVAX (3xxx, 6xxx) line ... (not to mention mypoor lowly
>>VAXstation II 8-( )
>
> True,
No, it ISN'T true. Both of you need up-to-date VAX Architecture Reference
Manuals:
"The base instruction group is defined by exception; it is those
instructions that may not be omitted in VAX processors announced
after 1986."
LOCC is included in the table showing the base instruction group. The
character-string portion of this group consists of:
CMPC3 CMPC5 LOCC MOVC3 MOVC5 SCANC SKPC SPANC
The CVAX line was announced after 1986. Yes, the VAXstation II was announced
earlier, and excludes LOCC.
(Section 11.1.1, _VAX Architecture Reference Manual_, second edition, 1991.)
> and finally, LOCC operates on at most 64k. This means you really need a
> loop of LOCC's, which admittedly will only run once most of the time, but still
> has to be there, making the output longer and wasting CPU cycles.
You're right there. But this check is done fairly efficiently. You do the
first LOCC and then check the Z-bit, which will be set if the zero-byte wasn't
located. In this case, R1 contains the address of the next byte after the
string, so your operands for subsequent LOCCs are all set up.
The fact that you need to count the characters at all is much more serious.
> Ah, but I was about to forget: "Nowadays, computers are fast and cheap".
Trouble is, we keep layering more and more software between the user and the
application, and between the application and the CPU. Or to put it another
way, there are three or four programmers whose code is all running at the same
time, all of whom were saying "nowadays, computers are fast and cheap, no need
to worry about speed optimization here". Those of us who have been with VMS
for a while have all seen the result: A one-VUP, 4 megabyte VAX (the 780) that
used to support 20 or so users under VMS 2.3 is not even adequate to support
one user today.
And it isn't all because of counted strings... Still, I wonder how many times
strlen() is being called per second inside DECwindows?
Hunter Goatley, WKU
Yes, it is.
[...]
> 4. FINALLY, some of you have drifted off to discussing Alpha
> and no BLISS on Alpha. While I agree here too, the original
> subject of this inanely-long thread has been:
> BLISS AND C, WHICH IS BETTER FOR VMS...
>
True. However, it *really* started with a request for Jamie's help in
getting DEC to bundle BLISS with Alpha, or at least acknowledge that they
plan to support it for customer use. The BLISS vs. C thing came about
through an (very calm and friendly, BTW) exchange between Jamie and me.
My original subject strayed from Alpha, but that's still foremost in my
head. I was interested, though, in finding out who had/hadn't used BLISS
and why they did/didn't. I think there've been sufficient answers posted
for both. Ultimately, it comes down to personal preference.
So, having started this, let me end it here with my hope that BLISS is
bundled with VMS to provide a *common* language between VAX and Alpha
that allows for systems programming and *isn't* MACRO-64 or whatever
they're calling it. Or, how about if DEC decides *now* that they will
support MACRO-32 as a real, honest-to-goodness supported language under
Alpha, not just as a transitional thing. Somebody (I don't remember who)
once had something like this in his SIG: "I'm still waiting for ANSI to
adopt MACRO-32 as a standard." I like that idea.... Or fix VAX C (or
release DEC C for VAX) so you'll be able to do the same things on VAX and
Alpha using common source.
>--
>Ehud Gavron (EG76)
>gav...@vesta.sunquest.com
>"The world bores you when you're cool."
Hunter
Steve McKinty - Sun ICNC
> >Plus, zero terminate strings are highly inefficient! Counted strings are
> >VERY efficient. BLISS lends itself to counted strings.
> >
> >ed_he...@npd.novell.com
>
> "highly" inefficient? just how much CPU time do you think is consumed
> by calculating the string length during the course of any application?
> maybe .00001% or so . . . *not* a hot spot by any stretch of the imagination.
>
> besides, there's the LOCC instruction to find the null byte for you,
> so even the actual calculation can't be too slow.
>
> ObTechNote: the 3B2 operating system has a machine instruction called STRCPY
> which copies an asciz string to a separate buffer, but has no
> equivalent to MOVC3, so copying a large number of binary bytes
> takes places 4 bytes at a time. now *there*'s a hot spot!
A similar situation applies on a MicroVAX II, where the LOCC instruction
is emulated, so strcpy() effectively does a byte-by-byte scan to find
the null and then calls movc3 to do the copy. Rewriting it so that the
byte-by-byte scan also copies can speed it up by a factor of more than 2x
>
d...@zl2tnm.gen.nz
>>>LOCC is also outside the "core" instruction set of the VAX architecture --
> Manuals:
OK. My Architecture book is the 1985 one, and only gets as far as the
MicroVAX I & II subsets.
> The fact that you need to count the characters at all is much more serious.
Yes. There are two problems with ASCIZ strings.
One: You have to search for the length. Slow if you're concatenating
strings or doing other things that don't require every character in the
string to be processed. This has a performance hit, but IMHO is the
lesser of the two problems.
Two: You cannot use the NUL character. I consider this a serious failing
in the "Unix/Posix/C RTL" world.
What is a string? To me, it's a chunk of memory. In the C world
however, a "string" and a "chunk of memory" are two different and subtly
incompatible things. In C (and I'm _not_ going to get drawn into a "oh
that's the RTL, not C" argument -- the C library is part of the
definition of the C language, and if you don't believe me, read the ANSI
spec), a "string" _cannot_ be used with binary data. Worse, a nul
character in a file, unless the code is either clever or special-cased,
will cause unexpected effects.
Having come from the commercial world, I consider strings to be the
most important datatype after integers. (Commercial applications get
_zero_ benefit from good FP performance, except where reals are used in
lieu of integers (and as integers) to get around architectural limits, eg
16 bit integers.) Why is it that these "computer science" languages
_always_ pay only lip service to them?
More to the point. Why the *hell* is anyone pushing C for commercial
applications?
Eric Thomas, SUNET
> 1. No matter whether the length is stored as a pre-counted
> string or as a null-terminated string, most uses for
> strings involve looping and doing something with all
> elements of the string.
Consider the very common case of comparing a string with a number of constants
for equality, as in the equivalent of a CASE statement, but based on a string
rather than a single character or integer. With null-terminated strings, you
happily call strcmp() (or equivalent) and check the sign of the result. The
routine reads bytes from both strings one after the other. With counted
strings, all it takes is:
CMPL string_length,#constant_length
BNEQ different
CMPC3 blahblahblah
BNEQ different
While the CMPC3 may or may not be implemented in hardware/microcode and be
faster than a CMPB loop, the CMPL sure beats anything that starts with a CALLx
for the case where the string hasn't got the same length as the constant, which
is very often in the CASE-like construct I chose for my example. These
constructs tend to be within loops - for instance, read all statements from
configuration file and process.
Eric
David P. Murphy
>> which copies an asciz string to a separate buffer, but has no
>> equivalent to MOVC3, so copying a large number of binary bytes
>> takes places 4 bytes at a time. now *there*'s a hot spot!
>>
> Dave, it would probably be more efficient to clear the last byte
> and use STRCPY. Once again, the issue of whether the length is
> pre-stored or not is irrelevant...
>
>GAV...@VESTA.SUNQUEST.COM (Ehud Gavron)
>"The world bores you when you're cool."
hello ehud. i'm sorry that you're so bored (;-) but if you re-read
my ObTechNote you will notice that the bytes to be copied are binary,
not printable. for instance:
struct FOO {
char name[20];
int age;
char city[30];
char state[2];
int zip;
};
foocopy(struct FOO *here, struct FOO *there)
{
movc3(sizeof(struct FOO), here, there);
}
obviously there is a large chance of hitting a null byte within one of
the "int" members, causing only the "name" and part of "age" to be copied
into the "there" space. placing a null byte at the end of "here",
while not only being very questionable and difficult, will accomplish nothing.
i did _not_ enjoy porting my VAX/VMS C code to the 3B2! :-(
ok
dpm
--
mur...@npri6.npri.com 602 Cameron St. Alexandria, VA 22314 (703) 683-9090
When every one is dead the Great Game is finished. Not before.
--- Hurree Babu, "Kim"
Terry Poot
In article <1992Apr27....@sunic.sunet.se>, er...@sejnet.sunet.se (Eric
Thomas, SUNET) writes:
>Consider the very common case of comparing a string with a number of constants
>for equality, as in the equivalent of a CASE statement, but based on a string
>rather than a single character or integer. With null-terminated strings, you
>happily call strcmp() (or equivalent) and check the sign of the result. The
>routine reads bytes from both strings one after the other.
Are you sure that's how it's written? It could just as easily get the lengths
first and then implement it much as the code you presented. Granted, still
slower, but if LOCC isn't emulated, probably not by a great deal.
>While the CMPC3 may or may not be implemented in hardware/microcode and be
>faster than a CMPB loop, the CMPL sure beats anything that starts with a CALLx
In-line support for the data type vs. an RTL routine is a much different issue
from string representation. It would be possible to build the strxxx() routines
into the C compiler, such that it (optionally) would generate in-line code.
That's a whole different issue from the specific string representation chosen.
>for the case where the string hasn't got the same length as the constant,
>which
>is very often in the CASE-like construct I chose for my example. These
>constructs tend to be within loops - for instance, read all statements from
>configuration file and process.
In which case how likely is it that the string comparison time is significant
when compared to the processing time? Also, in such cases, you probably have to
pull a command word off the front of the line anyway for comparison. If not,
(i.e. it was on a line by itself) you can generally find out how long it was
when it was read in. In either case, you'll know the length once you've done
that, so you could compare the lengths yourself and then use strncmp(). (You
could write a simple macro for that so it'd even look nice.) That should make
both implementations pretty much the same as far as performance, except for the
in-line vs. external issue, which is another matter entirely. In fact, in this
case, you could probably use a builtin (_CMPC3 ?). I haven't messed with those,
but I'd guess it's there.
#define NCMPSTR(string, length, const_string) \
((length) == sizeof(const_string)-1 && \
strncmp((string), (const_string), (length))
len = strlen(command); /* If you don't already know it */
if(NCMPSTR(command, len, "OPTION")){ /* process command OPTION */ }
else if(NCMPSTR(command, len, "EXIT")){ /* etc. */ }
--
Terry Poot <t...@mccall.com> The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp) 615 McCall Road
(800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA