25 Jun
2020
25 Jun
'20
3:14 p.m.
Hi,
Not hardware ... but an antique software / programming concept.
Some decades ago (circa late 1970s?), I *think* I came across a concept of
"raising the semantic level" of a program by using defines/macros and newly
written library functions. The concept was that a given language provided
a particular level of semantics. By judicious/clever use of things like
macros, one could "raise" the level of semantics, effectively appearing to
add new features to the language (or, in this case, the instance of the
language as used in the program).
I *thought* I got that concept from Terry Wingrad's excellent "Breaking the
Complexity Barrier again" (Nov, 1974,
https://dl.acm.org/doi/10.1145/951761.951764 )
...but, no. It's not in that paper.
Does the concept ring a bell?
Can anyone provide a pointer to where I might have seen it?
It's formed the basis of my own personal programming philosophy for nearly
50 years, and I want to know where I found it, or if I might have thought
of it myself.
thanks!
Stan
27 Jun
27 Jun
7:49 a.m.
Hi Stan
It sounds a little like the way most good Forth programmers deal with problems. Forth is
all about semantics. Every thing is a word. The complexity of the program is left to the
low level stuff. When the program is done, it isn't a program written in Forth, it is
a program written in the application. At the highest levels one should not see the
language it was written in one should only see the application. Well written Forth at the
upper levels has only : and ; of the language showing through. The rest are just the words
in a sentence like structure telling what the application is doing.
It is too bad that people insist on using languages that even at the highest level is
still just a program in that particular language. All the boiler plate is still in the way
of the program.
Although, taking a little more time to get used to, Lisp is something like that as well.
At least well written Lisp is. One can see what the intent is at the higher levels of
coding. It is just learning to read the sentences. The lower level language part is how
you move the bits and bytes around. The application should tell you what it does and why.
Comments should only be needed at the more confusing lower levels. At the higher levels
comments would and should be redundant. The words should tell you what is being done.
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Stan Sieler via cctalk
<cctalk at classiccmp.org>
Sent: Thursday, June 25, 2020 3:14 PM
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Subject: On: raising the semantic level of a program
Hi,
Not hardware ... but an antique software / programming concept.
Some decades ago (circa late 1970s?), I *think* I came across a concept of
"raising the semantic level" of a program by using defines/macros and newly
written library functions. The concept was that a given language provided
a particular level of semantics. By judicious/clever use of things like
macros, one could "raise" the level of semantics, effectively appearing to
add new features to the language (or, in this case, the instance of the
language as used in the program).
I *thought* I got that concept from Terry Wingrad's excellent "Breaking the
Complexity Barrier again" (Nov, 1974,
https://dl.acm.org/doi/10.1145/951761.951764 )
...but, no. It's not in that paper.
Does the concept ring a bell?
Can anyone provide a pointer to where I might have seen it?
It's formed the basis of my own personal programming philosophy for nearly
50 years, and I want to know where I found it, or if I might have thought
of it myself.
thanks!
Stan
6:15 p.m.
On 6/27/2020 8:49 AM, dwight via cctalk wrote:
Hi Stan
It sounds a little like the way most good Forth programmers deal with problems. Forth
is all about semantics. Every thing is a word. The complexity of the program is left to
the low level stuff. When the program is done, it isn't a program written in Forth, it
is a program written in the application. At the highest levels one should not see the
language it was written in one should only see the application. Well written Forth at the
upper levels has only : and ; of the language showing through. The rest are just the words
in a sentence like structure telling what the application is doing.
It is too bad that people insist on using languages that even at the highest level is
still just a program in that particular language. All the boiler plate is still in the way
of the program.
Although, taking a little more time to get used to, Lisp is something like that as well.
At least well written Lisp is. One can see what the intent is at the higher levels of
coding. It is just learning to read the sentences. The lower level language part is how
you move the bits and bytes around. The application should tell you what it does and why.
Comments should only be needed at the more confusing lower levels. At the higher levels
comments would and should be redundant. The words should tell you what is being done.
Dwight
At what point do variable names end being comments?
There needs to be more work on proper documenting and writing
programs and modules. I am not a fan of objects and operator overloading
because I never know just what the program is doing.
apples + oranges gives me what ? count of fruits, liters of fruit punch,
a error?
It would be nice if one could define a new language for problem
solving and run it through compiler-compiler processor for interesting
problems.
Ben.
28 Jun
28 Jun
3 a.m.
On Sat, Jun 27, 2020 at 07:15:25PM -0600, ben via cctalk wrote:
[...]
At what point do variable names end being comments?
There needs to be more
work on proper documenting and writing programs and modules.
What, auto-generated "documentation" which just lists function names and type
signatures is not useful? This is news to pretty much every Java project I've
had the misfortune of interacting with.
I am not a fan of objects and operator overloading
because I never know just
what the program is doing. apples + oranges gives me what ? count of fruits,
liters of fruit punch, a error?
That does of course depend on the strictness of the language's type system and
whether the developer has exercised good taste and discretion when using
operator overloading in their API. I would normally expect the compiler to
reject attempts to add two incompatible types, but this is often a triumph of
hope over experience. (But avoid PHP, JavaScript, and similar junk languages
hacked together in a Coke-fuelled bender to solve the immediate problem, and
you're 90% of the way there.)
It would be nice if one could define a new language
for problem solving and
run it through compiler-compiler processor for interesting problems.
I'm unclear on what you're trying to say here.
Source-to-source translators are of course a well-trodden path, such as early
C++ "compilers" which emitted C. A weaker variant is to abuse operator
overloading to create a minilanguage that is directly compilable without
translation. Such corner-cutting techniques are useful for prototyping new
ideas, but tend to cause more trouble than they are worth if used as-is in
production.
My day job currently involves PureScript, a Haskell-inspired language which is
translated into JavaScript. It is quite an experience.
11:06 a.m.
Overloading is always a problem in Forth. It is so easy to do that one sometimes loses the
context. I was writing an assembler for my 4004 project. I wanted to overload words like
IF THEN for cleaner to read assembly so I didn't have a lot of branch labels. I like
indenting to show beginning and ends of program flow control. I don't like doing
things like IFa and THENa or such to show the context. I still wanted to write my macros
in Forth and not in assembly, so I made a word Macro: to replace : so that it would
automatically keep the context straight. It is a crutch but sometimes a well placed crutch
can solve such context problems.
I now have my "CARRY IF ... THEN" in assembler and still can easily switch to
Forth's "IF ... THEN" for making macro commands that need flow control and
are for completely different context than the assembled code.
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Peter Corlett via
cctalk <cctalk at classiccmp.org>
Sent: Sunday, June 28, 2020 3:00 AM
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Subject: Re: On: raising the semantic level of a program
On Sat, Jun 27, 2020 at 07:15:25PM -0600, ben via cctalk wrote:
[...]
At what point do variable names end being comments?
There needs to be more
work on proper documenting and writing programs and modules.
What, auto-generated "documentation" which just lists function names and type
signatures is not useful? This is news to pretty much every Java project I've
had the misfortune of interacting with.
I am not a fan of objects and operator overloading
because I never know just
what the program is doing. apples + oranges gives me what ? count of fruits,
liters of fruit punch, a error?
That does of course depend on the strictness of the language's type system and
whether the developer has exercised good taste and discretion when using
operator overloading in their API. I would normally expect the compiler to
reject attempts to add two incompatible types, but this is often a triumph of
hope over experience. (But avoid PHP, JavaScript, and similar junk languages
hacked together in a Coke-fuelled bender to solve the immediate problem, and
you're 90% of the way there.)
It would be nice if one could define a new language
for problem solving and
run it through compiler-compiler processor for interesting problems.
I'm unclear on what you're trying to say here.
Source-to-source translators are of course a well-trodden path, such as early
C++ "compilers" which emitted C. A weaker variant is to abuse operator
overloading to create a minilanguage that is directly compilable without
translation. Such corner-cutting techniques are useful for prototyping new
ideas, but tend to cause more trouble than they are worth if used as-is in
production.
My day job currently involves PureScript, a Haskell-inspired language which is
translated into JavaScript. It is quite an experience.
12:39 p.m.
On 6/28/2020 12:06 PM, dwight via cctalk wrote:
Overloading is always a problem in Forth. It is so
easy to do that one sometimes loses the context. I was writing an assembler for my 4004
project. I wanted to overload words like IF THEN for cleaner to read assembly so I
didn't have a lot of branch labels. I like indenting to show beginning and ends of
program flow control. I don't like doing things like IFa and THENa or such to show the
context. I still wanted to write my macros in Forth and not in assembly, so I made a word
Macro: to replace : so that it would automatically keep the context straight. It is a
crutch but sometimes a well placed crutch can solve such context problems.
I now have my "CARRY IF ... THEN" in assembler and still can easily switch to
Forth's "IF ... THEN" for making macro commands that need flow control and
are for completely different context than the assembled code.
Dwight
A elseif would be easy to add I suspect to forth
I like the
"IF exep statements { EIF exep statments } {ELSE } ENDIF"
"WHILE exep statements REPEAT"
control structures because while { if {} else { if {} else .. }}
tends to be hard to find just what the last } belongs to if you have
several screens of code.
Now days you need to have more code to handle windows and other I/O than
pure problem solving as languages keep evolving.
Since I am working on a 1970's style computer ( blinking lights,
front panel,core memory, big rack with I/O devices) currently
being emulated in FPGA,I have been looking things from that era
rather than the modern stuff. It is sure hard to find a 16 or 32 bit cpu
that has simple byte accessing from that era. That may
be one of the reasons the PDP 11 and/or Unix developed the growth
of more modern software and programming ideas.
Ben.
1:32 p.m.
On 6/28/20 12:39 PM, ben via cctalk wrote:
On 6/28/2020 12:06 PM, dwight via cctalk wrote:
Since I am working on a 1970's style computer (
blinking lights,
front panel,core memory, big rack with I/O devices) currently
being emulated in FPGA,I have been looking things from that era
rather than the modern stuff. It is sure hard to find a 16 or 32 bit cpu
that has simple byte accessing from that era. That may
be one of the reasons the PDP 11 and/or Unix developed the growth
of more modern software and programming ideas.
Why is byte-granularity in addressing a necessity? It's only an issue
if you have instructions that operate directly on byte quantities in memory.
--Chuck
3:28 p.m.
On 6/28/2020 2:32 PM, Chuck Guzis via cctalk wrote:
Why is byte-granularity in addressing a necessity?
It's only an issue
if you have instructions that operate directly on byte quantities in memory.
Why have bytes in the first place then? A packed string does count here.
IBM started this mess with the 360 and 32 bits, and everybody
followed.Is Fortran I/O the BIBLE on character data.
IBM never seemed even to follow one character set encoding even with the
similar machines like the IBM 1130.
--Chuck
We don't have opcode space (now that we are 32 bits) to give a byte
LOAD/STORE but you can buy extra hardware for string functions seems to
have been the marketing idea back then.
Since punchcards I think had a 16 bit encoding, lack of byte data
was not big problem. Who used paper tape on a 360?
Ben.
4:18 p.m.
On 06/28/2020 05:28 PM, ben via cctalk wrote:
Since punchcards I think had a 16 bit encoding, lack of
byte data
was not big problem. Who used paper tape on a 360?
IBM punch cards had 12 rows of
holes. For alpha encoding,
logic in the controller
converted that to EBCDIC or your machine's favorite internal
character interpretation.
On the IBM 360, there was a straight binary encoding using
only 8 bits for the data (80 bytes/card) or using all 12
bits of two character positions to encode 3 bytes. that
way, you got 120 bytes/card.
I don't know any way to get 16-bit encoding on punch cards
of that format. Maybe some other manufacturer's punch card
format.
We had paper tape read and punch on a 360/50 at University
or Missouri at Rolla. It was used for compatibility with
the Data General minicomputers there. Only place I've ever
seen paper tape on a 360.
Jon
5:11 p.m.
On 6/28/2020 5:18 PM, Jon Elson wrote:
On 06/28/2020 05:28 PM, ben via cctalk wrote:
Bad choice of words. I looked at a IBM 1130 only for a short time and
all mostly remember you needed to convert data for every I/O device.
Since punchcards I think had a 16 bit encoding, lack of byte data
was not big problem. Who used paper tape on a 360?
IBM punch cards had 12 rows of
holes.? For alpha encoding, logic in the
controller
converted that to EBCDIC or your machine's favorite internal character
interpretation.
On the IBM 360, there was a straight binary encoding using only 8 bits
for the data (80 bytes/card) or using all 12 bits of two character
positions to encode 3 bytes.? that way, you got 120 bytes/card.
I don't know any way to get 16-bit encoding on punch cards of that
format.? Maybe some other manufacturer's punch card format. We had paper tape read and punch on a 360/50 at
University or Missouri
at Rolla.? It was used for compatibility with the Data General
minicomputers there.? Only place I've ever seen paper tape on a 360.
Jon
Ben.
4:22 p.m.
On 6/28/20 3:28 PM, ben via cctalk wrote:
On 6/28/2020 2:32 PM, Chuck Guzis via cctalk wrote:
There were lots of machines where the granularity was the word. The CDC
6000/7000/Cyber 60 bit machines, for example. The lack of byte
addressing did nothing to hold those machines back. At one point, CDC
had the fastest COBOL implementation, even though it lacked byte
addressing and decimal arithmetic, something that you'd think would give
an edge to the S/360 series. Chew on that one for awhile.
Punched cards (at least those of the 1130 era) used 12 bit encoding if
column-binary or 36 bit encoding if handling row-binary (e.g. 704; which
is why early programming languages used only the first 72 columns of a
card).
FWIW, I've also worked on bit-granular addressing systems, where bit
arrays were part of the instruction set.
--Chuck
Why is byte-granularity in addressing a
necessity?? It's only an issue
if you have instructions that operate directly on byte quantities in
memory.
Why have bytes in the first place then? A packed string does count here.
IBM started this mess with the 360 and 32 bits, and everybody
followed.Is Fortran I/O the BIBLE on character data.
IBM never seemed even to follow one character set encoding even with the
similar machines like the IBM 1130.
4:20 p.m.
On Sun, Jun 28, 2020 at 01:32:02PM -0700, Chuck Guzis via cctalk wrote:
[...]
Why is byte-granularity in addressing a necessity?
Because C's strings are broken by design and require one to be able to form a
pointer to individual characters.
It's only an issue if you have instructions that
operate directly on byte
quantities in memory.
One wheeze is to just declare that bytes are the same size as a machine word. C
doesn't require char to be exactly 8 bits, but merely at least 8 bits. However,
a lot of C code will break if char, short, int and long aren't exactly the same
size as they are on x86. Mind you, a lot of it is still broken even if they
are...
4:50 p.m.
On 6/28/20 4:20 PM, Peter Corlett via cctalk wrote:
On Sun, Jun 28, 2020 at 01:32:02PM -0700, Chuck Guzis
via cctalk wrote:
[...]
That's not a barrier, as IIRC, the C standard doesn't call out a
specific format for pointers, other than that of NULL.
I know that there was a C for the CDC Cyber series, but I don't recall
the implementation details.
It's noteworthy that on the Univac 1100 series, a "byte" could be 6, 9
or 12 bits, but not 8. (36 bit words). The PDP-10 had similar issues,
such as the "packed" string format of 5 7-bit characters per word, with
one bit unused.
Why is byte-granularity in addressing a
necessity?
Because C's strings are broken by design and require one to be able to form a
pointer to individual characters. One wheeze is to just declare that bytes are the same
size as a
machine word. C
doesn't require char to be exactly 8 bits, but
merely at least 8 bits. However,
a lot of C code will break if char, short, int and long aren't exactly the same
size as they are on x86. Mind you, a lot of it is still broken even if they
are...
Who cares about x86? I suspect that there's a lot of x86 code out there
that assumes little-endian quantities as well.
If you want to run code written for the x86 platform, get an x86 system.
--Chuck
29 Jun
29 Jun
12:41 p.m.
From: Chuck Guzis
Sent: Sunday, June 28, 2020 4:51 PM
It's noteworthy that on the Univac 1100 series, a
"byte" could be 6, 9
or 12 bits, but not 8. (36 bit words). The PDP-10 had similar issues,
such as the "packed" string format of 5 7-bit characters per word, with
one bit unused.
Of course, on the PDP-10, bytes can be anywhere from 1 to 36 bits long;
the size is defined in the pointer, not the hardware.
And in the 7-bit ASCII text format, bit 35 (the word is big-endian) *is*
used by the default editor: In order to allow line numbering in source
files for languages which do not allow it, the line numbers are ASCII
strings with bit 35 set, and the monitor (=kernel=operating system) strips
them out before handing them to compilers' input streams.
Rich
Rich Alderson
ex-Sr. Systems Engineer/Curator emeritus
Living Computers: Museum + Labs
2245 1st Ave S
Seattle, WA 98134
Cell: (206) 465-2916
Desk: (206) 342-2239
http://www.LivingComputers.org/
NB: This e-mail address will cease working after 1 July 2020. Use lcml at
alderson.users.panix.com for future communications.
6:01 p.m.
On 6/29/20 12:41 PM, Rich Alderson via cctalk wrote:
From: Chuck Guzis
Sent: Sunday, June 28, 2020 4:51 PM
My point being that implicit "byte" addressability isn't essential if
there are no instructions that can take advantage of it. The PDP-10
does have halfword instructions and although they're called "byte"
instructions, are what I'd call "bit field" instructions (LDB, DPB,
etc.)--but nothing that would implicitly be called a "byte".
Whereas, on say, S/360, an 8-bit byte is intrinsic to the hardware and
so defines addressing granularity.
Character sets on other systems can be wildly variable; consider WPS-8,
for example.
You do what works--and the lack of byte granularity is no particular
hindrance.
--Chuck
It's noteworthy that on the Univac 1100
series, a "byte" could be 6, 9
or 12 bits, but not 8. (36 bit words). The PDP-10 had similar issues,
such as the "packed" string format of 5 7-bit characters per word, with
one bit unused.
Of course, on the PDP-10, bytes can be anywhere from 1 to 36 bits long;
the size is defined in the pointer, not the hardware.
And in the 7-bit ASCII text format, bit 35 (the word is big-endian) *is*
used by the default editor: In order to allow line numbering in source
files for languages which do not allow it, the line numbers are ASCII
strings with bit 35 set, and the monitor (=kernel=operating system) strips
them out before handing them to compilers' input streams.
28 Jun
28 Jun
5:32 p.m.
On 6/28/2020 5:20 PM, Peter Corlett via cctalk wrote:
DISC I/O seems to have stage packed formats of bytes shorts and longs
all packed a character array. Directory structures or inodes come to mind.
The x86 is broken period.
'int' size depends on the compiler making porting programs interesting,
as well as macro processor and make files.
Ben.
On Sun, Jun 28, 2020 at 01:32:02PM -0700, Chuck Guzis
via cctalk wrote:
[...]
Just what is a NON broken string design?
Why is byte-granularity in addressing a
necessity?
Because C's strings are broken by design and require one to be able to form a
pointer to individual characters.
It's only
an issue if you have instructions that operate directly on byte
quantities in memory.
One wheeze is to just declare that bytes are the same size as a machine word. C
doesn't require char to be exactly 8 bits, but merely at least 8 bits. However,
a lot of C code will break if char, short, int and long aren't exactly the same
size as they are on x86. Mind you, a lot of it is still broken even if they
are...
7:32 p.m.
For the various flow control works, Forth generally teaches you to not spread flow control
across multiple pages. Unless you are really trying to reach for every last clock cycle,
it makes sense to factor even assembly code. It makes understanding the code easier and
allows one to think about what is happening in the code.
Of course, good choices of names make sense. One can even make a page long macro to paste
in-line a block of code for a zero cycle cost factoring.
Factoring is the key to such things. A page of straight assembly is a bad idea in the
first place.
I don't see creating labels spread across several pages any better then doing good
factoring.
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of ben via cctalk
<cctalk at classiccmp.org>
Sent: Sunday, June 28, 2020 5:32 PM
To: cctalk at classiccmp.org <cctalk at classiccmp.org>
Subject: Re: On: raising the semantic level of a program
On 6/28/2020 5:20 PM, Peter Corlett via cctalk wrote:
DISC I/O seems to have stage packed formats of bytes shorts and longs
all packed a character array. Directory structures or inodes come to mind.
The x86 is broken period.
'int' size depends on the compiler making porting programs interesting,
as well as macro processor and make files.
Ben.
On Sun, Jun 28, 2020 at 01:32:02PM -0700, Chuck Guzis
via cctalk wrote:
[...]
Just what is a NON broken string design?
Why is byte-granularity in addressing a
necessity?
Because C's strings are broken by design and require one to be able to form a
pointer to individual characters.
It's only
an issue if you have instructions that operate directly on byte
quantities in memory.
One wheeze is to just declare that bytes are the same size as a machine word. C
doesn't require char to be exactly 8 bits, but merely at least 8 bits. However,
a lot of C code will break if char, short, int and long aren't exactly the same
size as they are on x86. Mind you, a lot of it is still broken even if they
are... 
11:58 a.m.
ben wrote on Sat, 27 Jun 2020 19:15:25 -0600
It would be nice if one could define a new language
for problem
solving and run it through compiler-compiler processor for interesting
problems.
That is what Alan Kay's group did a few year ago in their "STEPS"
project. They wanted to implement a modern computing system in only 20
thousand lines of code, so they did a compiler-compiler called OMeta
inspired by the classic Meta II system and defined specialized languages
for each part of the system.
For networking, for example, they defined a language that was actually
the ASCII diagrams for packet formats from the RFCs. For graphics they
defined a sort of "APL meets streams" language called Nile in which a
Cairo-like graphics system (called Gezzira) could be described in just a
few hundred lines of code.
http://vpri.org/writings.php
Look for the texts with "STEPS" in the title - those are the yearly
reports to the NSF (2007 to 2012).
-- Jecel
12:18 a.m.
Hi Dwight,
Yes...I agree, sounds like how FORTH works.
BTW, I co-implemented a FORTH for the IBM PC, back when the first IBM PC
was released.
(Next Generation Systems FORTH ... 25% faster than the prior speed leader,
Laboratory Microsystems FORTH,
and it had a lot of nice concepts, like a true/accurate decompiler.)
My co-author was Carl Sassenrath, who then went on to write the kernel of
the AMIGA operating system,
and (later) the Rebol language. (Carl got the inner loop down to 3
instructions vs. LM's 4 instructions :)
Re: LISP ...
Yes, particularly with the advent of BBN-LISP (later named INTERLISP, then
INTERLisp) ... it had DWIM (Do What I Mean),
and a number of really neat things. I co-implemented the Burroughs B6500
version on an ARPA contract circa 1973,
so I got to interact with the BBN people a lot, including Danny Bobrow
(spaghetti stacks), who had recently moved
to Xerox PARC, IIRC.
One of the things in INTERLISP was an optional package that implemented
"normal" looking arithmetic expressions,
so one could do something like: (SETQ FOO (ARITH x * y + 3))
instead of (SETQ (FOO (+ (* x y) 3)))
(nearly 50 year old memory...it might have been higher level, like letting
me do: (foo = x * y + 3))
I recently found a 1978 version of our INTERLISP source code!
(both the normal interpreter, and our p-code interpreter ... not sure if
the LISP-to-pcode compiler is there)
thanks,
Stan
1409
days inactive
1414
days old
18 comments
8 participants
participants (8)
-
abuse＠cabal.org.uk -
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
dkelvey＠hotmail.com -
elson＠pico-systems.com -
jecel＠merlintec.com -
RichA＠livingcomputers.org -
sieler＠allegro.com