Ed, (01)
We mostly agree. Some comments about the fine points. (02)
JFS>> I usually use Common Logic as an example, but to make the
>> point more clearly, I'll use the assembly language for a typical
>> computer. (For me, that means IBM 360, but you can adapt it to
>> any other machine.) (03)
EB> Aside: Having taught this stuff, I think that the concept
> "typical computer" does not apply to the IBM 360, which had
> a hybrid architecture. (04)
Yes, but consider the earlier IBM 709 and 7090. The 709 was a
vacuum-tube machine, and the 7090 was a mapping of the 709 design
into transistors. Both machines had identical instruction sets
and data formats, but the 7090 was almost six times faster. The
later 7094 added a few more instructions, but it was exactly
upward compatible. Then there was the system that IBM built
for Project MAC at MIT: it had two memory banks of 32K words,
one for running the time-sharing system, and one for running
the user code. (05)
EB> In a certain sense, [360] architecture was a pattern for
> many machines to follow, including VAXes and the MC68K whose
> grandchildren probably populate your cell phones. (The Intel
> 80x86 series and its grandchildren had a significantly less
> flexible design.) (06)
The 704/709/7090 pattern inspired competitors' designs in the
same sense that the 360 did. In fact, when IBM switched to
the 360 architecture, GE lured away many customers with the
GE 635, which was, to a large extent, a cleaned-up 7094. (07)
JFS>> The semantics of the language is defined by the System/360
>> POP (Principles of Operation). (08)
EB> This is only partly true. IBM 360 Assembly language was rather
> more than a direct encoding of machine instructions....
>
> PL/360 had other architectural notions of software structures,
> such as a subprogram, as part of the language. (09)
I agree that the link-editor spec's and other conventions are
a significant extension that must be added to the POP manual. (010)
But the macros could be considered a purely syntactic extension
that did not alter the semantics -- each macro expanded into
a sequence of bit patterns that were indistinguishable from
what could have been written without the macros. (011)
In Annexes A and B of the CL standard, for example, we defined
"core" and "extended" versions of both CLIF and CGIF. The core
versions supported the full semantics, and we defined the
extended versions by macro expansions that supported some
convenient syntactic extensions. (012)
In fact, one could use those same extension mechanisms to go
much further, but we didn't want to overload the standard with
too much syntactic sugar. But other people with different
requirements are free to do so, if they choose. One could
implement the translation rules of Annex B in a translator
that would be simpler and more general than XSLT. (I modeled
them after a translator that I had implemented 30+ years ago.) (013)
EB> Regrettably, it also illustrates that languages tend to embody
> organizational stuff that is not the primary meat of the language
> but is critical to making it useful. (014)
I agree, but the qualifications to that would get into more
volumes of threads. (015)
John (016)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (017)
|