Bliss

[Arne Vajhøj]

So we got Bliss on VMS.

And we got Bliss for older DEC OS.

Are there any Bliss available for various Unix, Linux, Windows etc.?

Oracle supposedly did Bliss for Windows when they worked on Rdb for
Windows NT, but I believe that is not available.

Arne

[Simon Clubley]

Post by Arne Vajhøj
So we got Bliss on VMS.
And we got Bliss for older DEC OS.
Are there any Bliss available for various Unix, Linux, Windows etc.?

I sincerely hope not!!! :-)

We are talking about a language that has even less type safety than C...

Post by Arne Vajhøj
Oracle supposedly did Bliss for Windows when they worked on Rdb for
Windows NT, but I believe that is not available.

I wonder how Rdb for x86-64 is coming along ?

Simon.

[Arne Vajhøj]

Post by Arne Vajhøj
So we got Bliss on VMS.
And we got Bliss for older DEC OS.
Are there any Bliss available for various Unix, Linux, Windows etc.?
Oracle supposedly did Bliss for Windows when they worked on Rdb for
Windows NT, but I believe that is not available.

A little search find:

https://github.com/madisongh/blissc

(one familiar name)

Seems to require either autotools or cmake.

Arne

[Hunter Goatley]

Post by Arne Vajhøj

Post by Arne Vajhøj
So we got Bliss on VMS.
And we got Bliss for older DEC OS.
Are there any Bliss available for various Unix, Linux, Windows etc.?
Oracle supposedly did Bliss for Windows when they worked on Rdb for
Windows NT, but I believe that is not available.

https://github.com/madisongh/blissc
(one familiar name)
Seems to require either autotools or cmake.

I've never been able to get Matt's compiler to build. I also haven't
tried since I gained more experience working on Linux. I have meant to
try again, but never have made the time.

I had heard eons ago that DEC had a bunch of BLISS compilers: for RSTS,
for ULTRIX, for Windows. I don't know if they really did, but they were
certainly never made available outside of DEC, unfortunately.

Here's another one, which I just found and haven't tried.

https://github.com/JonathanBelanger/bliss

That page references another:

A FreeVMS Portable BLISS for GCC
ftp://freevms.nvg.org/pub/vms/freevms/bliss

The last version there is from 2007. No idea if it works, either.

Hunter

[Robert A. Brooks]

Post by Hunter Goatley
I had heard eons ago that DEC had a bunch of BLISS compilers: for
RSTS, for ULTRIX, for Windows. I don't know if they really did, but
they were certainly never made available outside of DEC,
unfortunately.

There were certainly compilers that generated bliss objects for the PDP-11, but they
were not hosted on a PDP-11; even the mighty, beloved task builder could not make it
fit.

[Lawrence D'Oliveiro]

Post by Robert A. Brooks
There were certainly compilers that generated bliss objects for the
PDP-11, but they were not hosted on a PDP-11; even the mighty, beloved
task builder could not make it fit.

Is Bliss more complex than Pascal? It was possible to get a (mostly
functional) Pascal compiler to fit by breaking it into two passes. The
Modula-2 compiler for the PDP-11 had no less than 5 passes.

[Robert A. Brooks]

Post by Lawrence D'Oliveiro

Post by Robert A. Brooks
There were certainly compilers that generated bliss objects for the
PDP-11, but they were not hosted on a PDP-11; even the mighty, beloved
task builder could not make it fit.

Is Bliss more complex than Pascal? It was possible to get a (mostly
functional) Pascal compiler to fit by breaking it into two passes. The
Modula-2 compiler for the PDP-11 had no less than 5 passes.

The Bliss master in residence at VSI will have to answer that.

[John H. Reinhardt]

Post by Robert A. Brooks

Post by Hunter Goatley
I had heard eons ago that DEC had a bunch of BLISS compilers: for
RSTS, for ULTRIX, for Windows. I don't know if they really did, but
they were certainly never made available outside of DEC,
unfortunately.

There were certainly compilers that generated bliss objects for the PDP-11, but they
were not hosted on a PDP-11; even the mighty, beloved task builder could not make it
fit.

An interesting coincidence, I was scanning through my "Downloads" folder, looking for something and came across a file named "bliss.pdf" from Feb 2024. I don't know where I got it, but it was an article "The BLISS programming language: a history by Ronald F. Brender" ©2002 John Wiley & Sons Ltd.

In it was this paragraph:

By the end of 1979, the new generation of self-hosted and highly-language compatible BLISS compilers was firmly established at DEC. We had BLISS-36 targetting and hosted on the PDP-10, BLISS-32 targetting the VAX-11 and hosted on both the PDP-10 and VAX-11, and BLISS-16 targetting the PDP-11 and hosted on both the PDP-10 and VAX-11.
In 1981 an attempt was made to shoe-horn a variant of BLISS-16 onto the PDP-11 using a combination of language subsetting, somewhat simplified code generation, and heavy overlaying. A constraint was that we were not willing to compromise much on code quality compared to that available from the BLISS-16 cross-compilers. While the resulting compiler generally worked, it was quite limited in the size of module it could compile, because the 65 Kbyte PDP-11 address space was just too small. The compromises were deemed too severe and the experiment was abandoned.

The whole article (it appears to be a clipping of chapter from a larger work) is quite an interesting discussion of BLISS. If I knew where I had downloaded it from, I'd include the link. Google did not readily find anything.

Oops. Never mind. A little better diffing found this:

https://www.cs.tufts.edu/~nr/cs257/archive/ronald-brender/bliss.pdf

Another quote from near the beginning, guaranteed to make Simon cringe ( :) )

BLISS is a typeless language; that is, all data is manipulated in terms of the underlying machine word sized units. The word size is usually the same as the integer or general purpose register size, which may be a multiple of the addressable unit size.

Enjoy...

[Lawrence D'Oliveiro]

Post by John H. Reinhardt
The whole article (it appears to be a clipping of chapter from a larger
work) is quite an interesting discussion of BLISS.

Interesting. TIL that PDP-11 Fortran-IV-Plus was written in BLISS, and
cross-compiled from a PDP-10. And that it wasn’t DEC’s first compiler
product written in a higher-level language.

[Rich Alderson]

Post by Lawrence D'Oliveiro

Post by John H. Reinhardt
The whole article (it appears to be a clipping of chapter from a larger
work) is quite an interesting discussion of BLISS.

Interesting. TIL that PDP-11 Fortran-IV-Plus was written in BLISS, and
cross-compiled from a PDP-10. And that it wasn't DEC's first compiler
product written in a higher-level language.

In point of fact, DEC's own Fortran-10 compiler (as opposed to the earlier F40
compiler which was provided by an outside vendor) was written in Bliss-10
(which was a CMU implementation of the language, available through DECUS, long
before DEC wrote their own Bliss-36 implementation).

[Hunter Goatley]

Post by John H. Reinhardt
https://www.cs.tufts.edu/~nr/cs257/archive/ronald-brender/bliss.pdf

There's also this article from Wulf, et al, from 1971. It was the
article that introduced BLISS to the world.

https://vms.process.com/scripts/fileserv/fileserv.com?BLISS-ARTICLE-PS

Hunter

[Simon Clubley]

Post by Robert A. Brooks

Post by Hunter Goatley
I had heard eons ago that DEC had a bunch of BLISS compilers: for
RSTS, for ULTRIX, for Windows. I don't know if they really did, but
they were certainly never made available outside of DEC,
unfortunately.

There were certainly compilers that generated bliss objects for the PDP-11, but they
were not hosted on a PDP-11; even the mighty, beloved task builder could not make it
fit.

$ set response/mode=good_natured

For those of us who had to work with overlay description files at the
start of our career, there's nothing beloved about that &$^#$^ TKB. :-)

Simon.

[bill]

Post by Simon Clubley

Post by Robert A. Brooks

Post by Hunter Goatley
I had heard eons ago that DEC had a bunch of BLISS compilers: for
RSTS, for ULTRIX, for Windows. I don't know if they really did, but
they were certainly never made available outside of DEC,
unfortunately.

There were certainly compilers that generated bliss objects for the PDP-11, but they
were not hosted on a PDP-11; even the mighty, beloved task builder could not make it
fit.

$ set response/mode=good_natured
For those of us who had to work with overlay description files at the
start of our career, there's nothing beloved about that &$^#$^ TKB. :-)

I ran overlayed programs all the time. My Ultrix-11 was a heavily
overlayed kernel to have room for networking. No big deal.

bill

[Single Stage to Orbit]

Post by Simon Clubley
For those of us who had to work with overlay description files at the
start of our career, there's nothing beloved about that &$^#$^ TKB. :-)

I ran overlayed programs all the time.  My Ultrix-11 was a heavily
overlayed kernel to have room for networking. No big deal.

I do remember building overlayed progrmas for MS-DOS, using interrupt
0x21 function 0x4B03, and files linked into separate .OVL files. One
could have code and data far greater than the actual memory limits,
very useful back in the bad old days before the 386 came along and gave
us 32bit flat mode and most usefully "voodoo" mode that allowed MSDOS
to run 32 bit programs and not need rebooting.

[Dave Froble]

Post by Simon Clubley

Post by Robert A. Brooks

Post by Hunter Goatley
I had heard eons ago that DEC had a bunch of BLISS compilers: for
RSTS, for ULTRIX, for Windows. I don't know if they really did, but
they were certainly never made available outside of DEC,
unfortunately.

There were certainly compilers that generated bliss objects for the PDP-11, but they
were not hosted on a PDP-11; even the mighty, beloved task builder could not make it
fit.

$ set response/mode=good_natured
For those of us who had to work with overlay description files at the
start of our career, there's nothing beloved about that &$^#$^ TKB. :-)
Simon.

+ 9999999999999999999999999999999999999999999

[Paul Hardy]

Post by Simon Clubley
For those of us who had to work with overlay description files at the
start of our career, there's nothing beloved about that &$^#$^ TKB. :-)

I still have bad dreams about debugging in the late 70s a big RSX
application using a complex TKB overlay tree, where the bug was a
subroutine call to a routine which was in another branch of the tree. The
called routine worked fine, but when it returned, it’s return point was now
an overwritten irrelevant instruction stream. Not easy to find. Not easy to
solve once the tree is complex to keep the runtime call sequence up and
down the tree, not across!

Moving to VAX and laying the code flat in virtual space was a great relief.

[Hunter Goatley]

Post by Hunter Goatley
Here's another one, which I just found and haven't tried.
https://github.com/JonathanBelanger/bliss

I installed cmake, llvm-dev, and clang on Ubuntu, but trying to compile
the first module results in twenty errors about missing templates and
members and it aborts.

If anyone tries it and gets it to work, let me know!

Hunter

[Hunter Goatley]

Post by Hunter Goatley

Post by Hunter Goatley
Here's another one, which I just found and haven't tried.
https://github.com/JonathanBelanger/bliss

I installed cmake, llvm-dev, and clang on Ubuntu, but trying to compile
the first module results in twenty errors about missing templates and
members and it aborts.
If anyone tries it and gets it to work, let me know!

After posting that, I realized that had been archived, and the creator
moved to GitLab.

https://gitlab.com/JonathanBelanger/bliss

The version there is four years old instead of five, but I get the same
errors trying to build it.

Hunter

[Hunter Goatley]

Post by Hunter Goatley
The version there is four years old instead of five, but I get the same
errors trying to build it.

I tried to contact Jonathan, but the email bounced, and GitLab wants you
to contact him via LinkedIn, but LinkedIn won't let me send a message
unless I sign up for Premium messaging, which I'm not going to do.

One of Jonathan's other projects is an Alpha emulator, DECaxp:

https://gitlab.com/JonathanBelanger/DECaxp

I can't remember if I've tried that or not. I've never been successful
in getting axpbox to run. The last time I tried that, it would start to
boot, but crashed during booting.

Hunter

[Hunter Goatley]

Post by Hunter Goatley
I've never been able to get Matt's compiler to build. I also haven't
tried since I gained more experience working on Linux. I have meant to
try again, but never have made the time.

Success! In addition to installing llvm-dev, I needed to install a
specific llvm-dev. I chose the latest, llvm-15-dev, and then I had to
edit one file to point to the new include directory:

$ diff llvm_helper.cpp llvm_helper.BAK
22,23c22,23
< #include "llvm/Support/Alignment.h"
< #include "llvm/Support/Host.h"
---

Post by Hunter Goatley
#include "llvm/MC/Alignment.h"
#include "llvm/MC/Host.h"

***@pmxx-u:llvmgen$

After I did that, Matt's blissc built cleanly. I have not yet tried to
use it, but it does pass the checks.

Thanks for inspiring me to try again.

Hunter

[Hunter Goatley]

Post by Hunter Goatley
I chose the latest, llvm-15-dev, and then I had to

It looks like I could have also used CMake and specified the correct
directory. Matt provides instructions for using Autotools (which I did)
and CMake.

Hunter

[Lawrence D'Oliveiro]

Post by Hunter Goatley
Success! In addition to installing llvm-dev, I needed to install a
specific llvm-dev. I chose the latest, llvm-15-dev, and then I had to

Is that the madisongh one? I got more errors than that. But I have a range
of versions of llvm currently installed, and the oldest one, 13, seemed to
do the trick. (The build requirement is for 12 or later.)

Now I actually need to try compiling some code with it...

[Hunter Goatley]

Post by Lawrence D'Oliveiro

Post by Hunter Goatley
Success! In addition to installing llvm-dev, I needed to install a
specific llvm-dev. I chose the latest, llvm-15-dev, and then I had to

Is that the madisongh one? I got more errors than that. But I have a range
of versions of llvm currently installed, and the oldest one, 13, seemed to
do the trick. (The build requirement is for 12 or later.)

Yes, this is the madisongh blissc compiler. I also have more than one
version of llvm-xx-dev installed. On my ARM system, I had to use
llvm-14-dev to get it to work.

Post by Lawrence D'Oliveiro
Now I actually need to try compiling some code with it...

It's not much, but I successfully compiled a module. It complains about
MAIN=main, and I'm not sure why, but I successfully created a .c with a
main() that called my routine in the BLISS module (which called back to
the C module to actually print some output). Pretty slick!

Hunter

[Lawrence D'Oliveiro]

Post by Hunter Goatley
It's not much, but I successfully compiled a module. It complains about
MAIN=main, and I'm not sure why, but I successfully created a .c with a
main() that called my routine in the BLISS module (which called back to
the C module to actually print some output). Pretty slick!

I was able to compile this example adapted from page 1-15 of the May
1987 “Bliss Language Reference Manual”:

MODULE E1 (MAIN = CTRL) =
BEGIN

FORWARD ROUTINE
CTRL,
STEP;

GLOBAL ROUTINE CTRL =
!+
! This routine inputs a value, operates on it, and
! then outputs the result.
!-
BEGIN
EXTERNAL ROUTINE
GETNUM, ! Input a number from terminal
PUTNUM; ! Output a number to terminal
LOCAL
X, ! Storage for input value
Y; ! Storage for output value
GETNUM(X);
Y = STEP(.X);
PUTNUM(.Y)
END;

ROUTINE STEP(A) =
!+
! This routine adds 1 to the given value.
!-
(.A+1);

END ELUDOM

That “MAIN =” elicited no complaints, but neither did it seem to do
anything useful. I was able to link the compiled code against this
driver program:

#include <stdio.h>

void GETNUM
(
int * x
)
{
*x = 99;
} /*getnum*/

void PUTNUM
(
int x
)
{
fprintf(stdout, "putnum(%d)\n", x);
} /*putnum*/

void CTRL(void);

int main(void)
{
CTRL();
return
0;
} /*main*/

And it output the message “putnum(100)”, as expected.

[Lawrence D'Oliveiro]

Slightly more elaborate example, doing some environment enquiries:

module e2 =
begin

global routine bmain =
begin
external routine putnums;
putnums
(
uplit(%ascii'%%bpval = %d, %%bpunit = %d, %%bpaddr = %d, %%upval = %d', 10, 0),
%bpval, %bpunit, %bpaddr, %upval
);
end;

end eludom

C driver:

#include <stdio.h>

extern void BMAIN();

void PUTNUMS
(
const char * fmt,
int bpval,
int bpunit,
int bpaddr,
int upval
)
{
fprintf
(
stdout, fmt,
bpval, bpunit, bpaddr, upval
);
} /*putnums*/

int main(void)
{
BMAIN();
return
0;
} /*main*/

Output:

%bpval = 64, %bpunit = 8, %bpaddr = 64, %upval = 8

Slightly annoying that global names must be uppercased.

Also I wonder if I can get varargs to work ...

[Hunter Goatley]

That's a little more extensive than what my test had done. very nice.

Post by Lawrence D'Oliveiro
%bpval = 64, %bpunit = 8, %bpaddr = 64, %upval = 8
Slightly annoying that global names must be uppercased.

Yeah.

Post by Lawrence D'Oliveiro
Also I wonder if I can get varargs to work ...

In the C? Yes. Take a look at blissc/tests. testharness.req uses
test_printf(), which is defined in testharness.c, which uses va_list(),
va_start(), and vprintf() for the arguments.

Hunter

[Lawrence D'Oliveiro]

Post by Lawrence D'Oliveiro
Slightly annoying that global names must be uppercased.

Yeah.

Tried this patch, and my compiler build is now case-sensitive. Builtin
and reserved names must still be uppercased, but your own symbols
(particularly references to names defined in C code) can be
lowercased:

diff -u lib/frontend/scanner.c{-orig,}
--- lib/frontend/scanner.c-orig 2024-07-13 10:52:16.426465872 +1200
+++ lib/frontend/scanner.c 2024-07-18 15:39:51.026148083 +1200
@@ -75,8 +75,8 @@
'0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 0, 0, 0, 0, 0, 0,
0, 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O',
'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', 0, 0, 0, 0, '_',
- 0, 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O',
- 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', 0, 0, 0, 0, 0,
+ 0, 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o',
+ 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z', 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

[Hunter Goatley]

Post by Lawrence D'Oliveiro

Post by Lawrence D'Oliveiro
Slightly annoying that global names must be uppercased.

Yeah.

Tried this patch, and my compiler build is now case-sensitive. Builtin
and reserved names must still be uppercased, but your own symbols
(particularly references to names defined in C code) can be

Thanks! I hadn't had time to go look for it. I'm OK with the builtin and
reserved names being uppercase. I've always done that. 8-)

Hunter

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Lawrence D'Oliveiro
Slightly annoying that global names must be uppercased.

Yeah.

Tried this patch, and my compiler build is now case-sensitive. Builtin
and reserved names must still be uppercased, but your own symbols
(particularly references to names defined in C code) can be
diff -u lib/frontend/scanner.c{-orig,}
--- lib/frontend/scanner.c-orig 2024-07-13 10:52:16.426465872 +1200
+++ lib/frontend/scanner.c 2024-07-18 15:39:51.026148083 +1200
@@ -75,8 +75,8 @@
'0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 0, 0, 0, 0, 0, 0,
0, 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O',
'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', 0, 0, 0, 0, '_',
- 0, 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O',
- 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', 0, 0, 0, 0, 0,
+ 0, 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o',
+ 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z', 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

I think that is a good change.

Uppercasing makes sense on VMS - that is traditional VMS
behavior.

Compile with /NAME=AS_IS, link with option case_sensitive=YES
etc. are a PITA.

But this compiler is on Linux and I find it difficult to
see any case where uppercasing makes sense.

Matt should include it. Possible as an option, but please
on by default.

Arne

[Lawrence D'Oliveiro]

Post by Lawrence D'Oliveiro
uplit(%ascii'%%bpval = %d, %%bpunit = %d, %%bpaddr = %d, %%upval = %d', 10, 0),

That line should be (with all-uppercased reserved/builtin words now):

UPLIT BYTE(%ASCII'%%bpval = %d, %%bpunit = %d, %%bpaddr = %d, %%upval = %d', 10, 0),

Without the BYTE, each item was taking up a fullword, so the trailing null
was actually part of the fullword holding the newline.

[Hunter Goatley]

Post by Lawrence D'Oliveiro

Post by Hunter Goatley
It's not much, but I successfully compiled a module. It complains about
MAIN=main, and I'm not sure why, but I successfully created a .c with a
main() that called my routine in the BLISS module (which called back to
the C module to actually print some output). Pretty slick!

I was able to compile this example adapted from page 1-15 of the May

That's roughly what my test did, too. 8-)

Post by Lawrence D'Oliveiro
That “MAIN =” elicited no complaints, but neither did it seem to do
anything useful.

Right. I should have elaborated. It complained about "MAIN=main", but
did not complain about "MAIN=something else". But it also doesn't treat
"something else" as main(). I'm not sure if that's a bug or a feature. 8-)

Hunter

[Lawrence D'Oliveiro]

Post by Lawrence D'Oliveiro
That “MAIN =” elicited no complaints, but neither did it seem to do
anything useful.

The routine referenced by the “MAIN =” directive is checked for
validity in lib/frontend/declarations.c:

text = modsym_main(np);
if (text != 0) {
scopectx_t blkscope = expr_blk_scope(blkexp);
name_t *mainrtn = 0;
if (blkscope != 0) {
mainrtn = rtnsym_search(blkscope, text);
if (mainrtn != 0) {
if (rtnsym_expr(mainrtn) == 0) {
expr_signal(ctx, STC__MNTYPERR, text);
}
}
}
if (mainrtn == 0) {
expr_signal(ctx, STC__NOMAIN, text);
}
string_free(expr_strctx(ctx), text);
}

but in lib/llvmgen/llvm_gencode.c, where it would be used to set the
start address in the generated code, that part is disabled:

#if 0 // XXX later
headerlen = 0;
str = modsym_ident(modnp);
if (str != 0) {
int reslen, len = str->len;
reslen = snprintf(module_header+headerlen, sizeof(module_header)-headerlen,
"\t.ident %-*.*s", len, len, str->ptr);
if (reslen > 0) headerlen += reslen;
}
str = modsym_main(modnp);
if (str != 0) {
int reslen, len = str->len;
if (headerlen > 0) module_header[headerlen++] = '\n';
reslen = snprintf(module_header+headerlen, sizeof(module_header)-headerlen,
"\t.set start,_%-*.*s", len, len, str->ptr);
if (reslen > 0) headerlen += reslen;
}
if (headerlen > 0) {
module_header[headerlen] = '\0';
LLVMSetModuleInlineAsm(gctx->module, module_header);
}
#endif // XXX later

I wonder if that code actually works?

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Lawrence D'Oliveiro
That “MAIN =” elicited no complaints, but neither did it seem to do
anything useful.

The routine referenced by the “MAIN =” directive is checked for
but in lib/llvmgen/llvm_gencode.c, where it would be used to set the
I wonder if that code actually works?

Do you need it?

***@arnepc6:~$ cat newtest.b32
MODULE HELLOWORLD (MAIN=main)=
BEGIN

GLOBAL ROUTINE main =
BEGIN
EXTERNAL ROUTINE puts;
puts(UPLIT(%ASCIZ'Hello world!'))
END;

END
ELUDOM
***@arnepc6:~$ blissc-master/blissc newtest.b32
***@arnepc6:~$ gcc newtest.o -o newtest
***@arnepc6:~$ ./newtest
Hello world!
***@arnepc6:~$

Arne

[Lawrence D'Oliveiro]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro
I wonder if that code actually works?

Do you need it?

Probably not. ;)

[Hunter Goatley]

Post by Arne Vajhøj
Hello world!

Interesting. I copied and pasted your sample program, and I get the same
thing I get with all of my tests: it complains about expecting a name,
and then it goes into an infinite loop. I can only get past that if I
specify some name besides "main" for the main routine.

-----------------------------------------------------
***@zaius:bliss$ blissc test.b32
MODULE HELLOWORLD (MAIN=main)=
........................|
%BLISS-W-NAMEEXP, name expected
- at /home/hunter/tmp/bliss/test.b32:1:25
MODULE HELLOWORLD (MAIN=main)=
........................|
%BLISS-W-DELIMEXP, expected delimiter ','
- at /home/hunter/tmp/bliss/test.b32:1:25
MODULE HELLOWORLD (MAIN=main)=
............................|
%BLISS-W-DELIMEXP, expected delimiter '='
- at /home/hunter/tmp/bliss/test.b32:1:29
MODULE HELLOWORLD (MAIN=main)=
............................|
%BLISS-W-NAMEEXP, name expected
- at /home/hunter/tmp/bliss/test.b32:1:29
GLOBAL ROUTINE main =
...............|
%BLISS-W-NAMEEXP, name expected
- at /home/hunter/tmp/bliss/test.b32:4:16
^C
***@zaius:bliss$
-----------------------------------------------------

And if I change to "MAIN=test", I get:

***@zaius:build$ ./blissc ~/tmp/bliss/test.b32
***@zaius:build$ gcc test.o -o test
/usr/bin/ld:
/usr/lib/gcc/aarch64-linux-gnu/11/../../../aarch64-linux-gnu/Scrt1.o: in
function `_start':
(.text+0x1c): undefined reference to `main'
/usr/bin/ld: (.text+0x20): undefined reference to `main'
/usr/bin/ld: test.o: in function `TEST':
HELLOWORLD:(.text+0xc): undefined reference to `PUTS'
collect2: error: ld returned 1 exit status
***@zaius:build$

Also, where is your puts() coming from?

Hunter

[Hunter Goatley]

Post by Hunter Goatley
Interesting. I copied and pasted your sample program, and I get the same
thing I get with all of my tests: it complains about expecting a name,
and then it goes into an infinite loop. I can only get past that if I
specify some name besides "main" for the main routine.

OK. I had not applied Lawrence's patch yet. After applying that, the
sample compiles OK. Thanks!

Post by Hunter Goatley
Also, where is your puts() coming from?

Ah, I get it now. The use of gcc to do the link pulls it in from the C
RTL. I hadn't thought about that before.

Thanks!

Hunter

[Arne Vajhøj]

Post by Hunter Goatley

Post by Hunter Goatley
Interesting. I copied and pasted your sample program, and I get the
same thing I get with all of my tests: it complains about expecting a
name, and then it goes into an infinite loop. I can only get past that
if I specify some name besides "main" for the main routine.

OK. I had not applied Lawrence's patch yet. After applying that, the
sample compiles OK. Thanks!

That was a prerequisite for this little trick.

Post by Hunter Goatley

Post by Hunter Goatley
Also, where is your puts() coming from?

Ah, I get it now. The use of gcc to do the link pulls it in from the C
RTL. I hadn't thought about that before.

On VMS you use LIB$ and SYS$ calls.

On Linux using C RTL seems to be the best equivalent.

Arne

[Hunter Goatley]

Post by Arne Vajhøj

Post by Hunter Goatley
Ah, I get it now. The use of gcc to do the link pulls it in from the C
RTL. I hadn't thought about that before.

On VMS you use LIB$ and SYS$ calls.
On Linux using C RTL seems to be the best equivalent.

Definitely! I just had envisioned the need for C wrappers. I hadn't
thought doing the link with gcc so the C RTL routines would get linked
without the need for wrapper routines. Makes total sense, now.

Hunter

[Lawrence D'Oliveiro]

Currently working my way through AA_H275C-TK (1983 edition). Adapted
this example from page 15-9:

MODULE quote_test_1 =
BEGIN
OWN x;
LITERAL mark = 4;
MACRO m = mark + %UNQUOTE mark %;

GLOBAL ROUTINE doit : NOVALUE =
BEGIN
LITERAL mark = 5;
x = m;
END;

END ELUDOM

When I look at the generated assembler

doit:
...
movq $10, x(%rip)
retq

That value should be 9, not 10.

[Hunter Goatley]

Post by Lawrence D'Oliveiro
Currently working my way through AA_H275C-TK (1983 edition). Adapted

[...]

Post by Lawrence D'Oliveiro
That value should be 9, not 10.

Oops. That said, I have never used %UNQUOTE in all of the BLISS I've
done. Learn something new every day! 8-)

Hunter

[John Reagan]

Post by Lawrence D'Oliveiro
Currently working my way through AA_H275C-TK (1983 edition). Adapted
MODULE quote_test_1 =
BEGIN
OWN x;
LITERAL mark = 4;
MACRO m = mark + %UNQUOTE mark %;
GLOBAL ROUTINE doit : NOVALUE =
BEGIN
LITERAL mark = 5;
x = m;
END;
END ELUDOM
When I look at the generated assembler
...
movq $10, x(%rip)
retq
That value should be 9, not 10.

What compiler is that from? That isn't even PIC code. And the $10 in
the output is hex 10.

[Craig A. Berry]

Post by Lawrence D'Oliveiro
Currently working my way through AA_H275C-TK (1983 edition). Adapted
     MODULE quote_test_1 =
     BEGIN
         OWN x;
         LITERAL mark = 4;
         MACRO m = mark + %UNQUOTE mark %;
         GLOBAL ROUTINE doit : NOVALUE =
         BEGIN
             LITERAL mark = 5;
             x = m;
         END;
     END ELUDOM
When I look at the generated assembler
         ...
         movq    $10, x(%rip)
         retq
That value should be 9, not 10.

What compiler is that from?  That isn't even PIC code.  And the $10 in
the output is hex 10.

I think they said up-thread they are tinkering with Matt Madison's blissc:

https://github.com/madisongh/blissc

[Arne Vajhøj]

Post by Lawrence D'Oliveiro
Currently working my way through AA_H275C-TK (1983 edition). Adapted
     MODULE quote_test_1 =
     BEGIN
         OWN x;
         LITERAL mark = 4;
         MACRO m = mark + %UNQUOTE mark %;
         GLOBAL ROUTINE doit : NOVALUE =
         BEGIN
             LITERAL mark = 5;
             x = m;
         END;
     END ELUDOM
When I look at the generated assembler
         ...
         movq    $10, x(%rip)
         retq
That value should be 9, not 10.

What compiler is that from?  That isn't even PIC code.  And the $10 in
the output is hex 10.

Matt Madisons open source Bliss compiler running on
Linux.

So not one of your compilers. :-)

Arne

[Lawrence D'Oliveiro]

Matt Madisons open source Bliss compiler running on Linux.

With the case-sensitivity patch. ;)

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Matt Madisons open source Bliss compiler running on Linux.

With the case-sensitivity patch. ;)

Yes.

But I doubt that is relevant for the UNQUOTE problem.

Arne

[John Reagan]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro
Currently working my way through AA_H275C-TK (1983 edition). Adapted
     MODULE quote_test_1 =
     BEGIN
         OWN x;
         LITERAL mark = 4;
         MACRO m = mark + %UNQUOTE mark %;
         GLOBAL ROUTINE doit : NOVALUE =
         BEGIN
             LITERAL mark = 5;
             x = m;
         END;
     END ELUDOM
When I look at the generated assembler
         ...
         movq    $10, x(%rip)
         retq
That value should be 9, not 10.

What compiler is that from?  That isn't even PIC code.  And the $10 in
the output is hex 10.

Matt Madisons open source Bliss compiler running on
Linux.
So not one of your compilers. :-)
Arne

Ah, that makes sense. My BLISS would generate

DOIT::
00000000: pushq %rbp # 000007
00000001: movq %rsp,%rbp
00000004: movq ***@GOTPCREL(%rip),%rax # 000010
0000000B: movl $00000009,(%rax)
00000011: popq %rbp # 000011
00000012: retq

[Lawrence D'Oliveiro]

This version does work:

MODULE quote_test_2 =
BEGIN
OWN x;
MACRO mark = 4 %;
MACRO m = (mark) + %UNQUOTE mark %;

GLOBAL ROUTINE doit : NOVALUE =
BEGIN
MACRO %QUOTE mark = 5 %;
x = m;
END;

END ELUDOM

But note the parentheses around “(mark)”; it doesn’t seem to get the
addition right without that.

Generated code:

doit:
...
movq $9, x(%rip)
retq

The problem seems to be that the handling of the %UNQUOTE construct is
only expecting the following name to be that of a macro, not a literal or
anything else.

[bill]

Post by Arne Vajhøj
So we got Bliss on VMS.
And we got Bliss for older DEC OS.
Are there any Bliss available for various Unix, Linux, Windows etc.?
Oracle supposedly did Bliss for Windows when they worked on Rdb for
Windows NT, but I believe that is not available.

Wish I had Bliss for the PDP-11. Especially one that generated MACRO
so I could use it on any OS. :-)

bill