23 Jun
2021
23 Jun
'21
2:02 p.m.
On 6/23/21 1:14 PM, Paul Koning wrote:
I don't remember the details at this point, but I
assume the "execute TECO macro" operation in the Stevens PDP-10 TECO compiler is
done in that way. And of course these could keep the compiled code around to reuse if the
source string hasn't changed. A modern example of this technique is the regex library
in Python, which lets you compile a regex string into a compiled regex object for later
use, or lets you perform operations using the regex string directly. The latter form
caches a string -> compiled regex cache so doing this in a loop still performs
reasonably well.
Could be the case of "what does "compile" mean?" If the meaning is
"reduce to machine language" maybe not. Otherwise, if the meaning is
"interpret", then maybe so.
Consider this paragraph of the tutorial at
http://www.snobol4.org/docs/burks/tutorial/ch7.htm"
--------------------------------------------------------
7.7 RUN-TIME COMPILATION
The two functions described below are among the most esoteric features,
not just of SNOBOL4, but of all programming languages in existence.
While your program is executing, the entire SNOBOL4 compiler is just a
function call away.
-----------------------------------------------------------
So maybe not rendering into machine code, but something else.
--Chuck
23 Jun
23 Jun
2:18 p.m.
On Jun 23, 2021, at 5:02 PM, Chuck Guzis <cclist at
sydex.com> wrote:
On 6/23/21 1:14 PM, Paul Koning wrote:
I meant "reduce to machine language" (give or take threaded code or library
function calls). It really doesn't seem to be any particular problem. There's
nothing about compilers that prevents them from being invoked in the middle of an
application. (Come to think of it, isn't that what a "just in time
compiler" means?)
paul
I don't remember the details at this point,
but I assume the "execute TECO macro" operation in the Stevens PDP-10 TECO
compiler is done in that way. And of course these could keep the compiled code around to
reuse if the source string hasn't changed. A modern example of this technique is the
regex library in Python, which lets you compile a regex string into a compiled regex
object for later use, or lets you perform operations using the regex string directly. The
latter form caches a string -> compiled regex cache so doing this in a loop still
performs reasonably well.
Could be the case of "what does "compile" mean?" If the meaning is
"reduce to machine language" maybe not. Otherwise, if the meaning is
"interpret", then maybe so.
Consider this paragraph of the tutorial at
http://www.snobol4.org/docs/burks/tutorial/ch7.htm"
--------------------------------------------------------
7.7 RUN-TIME COMPILATION
The two functions described below are among the most esoteric features,
not just of SNOBOL4, but of all programming languages in existence.
While your program is executing, the entire SNOBOL4 compiler is just a
function call away.
-----------------------------------------------------------
So maybe not rendering into machine code, but something else.
--Chuck
5:23 p.m.
On 6/23/21 2:18 PM, Paul Koning wrote:
I meant "reduce to machine language" (give or take threaded code or library
function calls). It really doesn't seem to be any particular problem. There's
nothing about compilers that prevents them from being invoked in the middle of an
application. (Come to think of it, isn't that what a "just in time
compiler" means?)
Yeah, come to think of it the "JIT compiler" idea did occur to me as
being the case.
5:48 p.m.
Somewhat related to the point of compiling and executing mixed together is a very strange
hack I saw in the Electrologica assembler for the X8 (the company issue one, not one of
the various ones built at various labs for that machine). It is essentially a "load
and go" assembler, so the code is dropped into memory as it is assembled, with a list
of places to be fixed up rather than the more typical two pass approach. You can use a
variation of the usual "start address" directive to tell the assembler to start
executing at that address right now. In other words, you can assemble some code, execute
it, then go back to assembling the rest of the source text. Cute. Suppose you want to do
something too hard for macros; just assemble its input data, followed by some code to
convert that into the form you want, then go back to assembling more code. And that can
start by backing up the assembly output pointer ("dot") so the conversion code
doesn't actually take up space in the finished program.
It sure makes cross-assemblers hard, because you have to include an EL-X8 simulator in the
assembler... :-)
paul
6:02 p.m.
On Wed, 2021-06-23 at 20:48 -0400, Paul Koning via cctalk wrote:
In other words, you can assemble some code, execute
it, then go back
to assembling the rest of the source text. Cute. Suppose you want
to do something too hard for macros; just assemble its input data,
followed by some code to convert that into the form you want, then go
back to assembling more code.
I proposed this for Fortran about twenty years ago, and for what became
Ada when it was just DoD\1 requirements in about 1976.
10:02 p.m.
On 2021-06-23 6:48 p.m., Paul Koning via cctalk wrote:
Somewhat related to the point of compiling and
executing mixed together is a very strange hack I saw in the Electrologica assembler for
the X8 (the company issue one, not one of the various ones built at various labs for that
machine). It is essentially a "load and go" assembler, so the code is dropped
into memory as it is assembled, with a list of places to be fixed up rather than the more
typical two pass approach. You can use a variation of the usual "start address"
directive to tell the assembler to start executing at that address right now. In other
words, you can assemble some code, execute it, then go back to assembling the rest of the
source text. Cute. Suppose you want to do something too hard for macros; just assemble
its input data, followed by some code to convert that into the form you want, then go back
to assembling more code. And that can start by backing up the assembly output pointer
("dot") so the conversion code doesn't actually take up space in the
finished program.
It sure makes cross-assemblers hard, because you have to include an EL-X8 simulator in
the assembler... :-)
paul
But at least it not a 386. Did any other computers have built in rom or
protected core used as rom for 'standard' routines like I/O or floating
point.
Ben.
24 Jun
24 Jun
8:02 a.m.
On Jun 24, 2021, at 1:02 AM, ben via cctalk <cctalk
at classiccmp.org> wrote:
On 2021-06-23 6:48 p.m., Paul Koning via cctalk wrote:
Sure. A few examples:
The Electrologica X1 (from 1958) has what one might call the first BIOS, in core ROM; the
standard version (by E.W. Dijkstra, see his Ph.D. thesis) contains basic I/O services, a
rudimentary assembler, and some operator interface mechanisms. Customers could order
additional ROM, and several did to add run time library routines for their compilers to
the ROM, things like floating point operations since the hardware did only integer
arithmetic.
The Electrologica X8 (1964) had an I/O coprocessor called CHARON which the main machine
talks to via semaphores and queues; it does the detailed control of the various
peripherals. It either came with ROM or with read/write core loaded at the factory,
I'm not sure. It wasn't customer-programmable.
The IBM 360/44 (early 1970s) with the very obscure Emulator option implements an emulation
of the string and decimal instructions of the 360 instruction set in an emulator that
lives in a separate memory, not addressable from the normal execution environment.
It's read/write core memory, loaded (if it ever gets messed up, which I never saw
happen) from a binary card deck using the "Emulator IPL" console button.
I assume the Apollo Guidance Computer (1968 or thereabouts) is an example since it has a
substantial core ROM, and also I believe loadable programs, but I don't know the
details.
There probably are quite a lot more but those are a few I know of.
paul
Somewhat related to the point of compiling and
executing mixed together is a very strange hack I saw in the Electrologica assembler for
the X8 (the company issue one, not one of the various ones built at various labs for that
machine). It is essentially a "load and go" assembler, so the code is dropped
into memory as it is assembled, with a list of places to be fixed up rather than the more
typical two pass approach. You can use a variation of the usual "start address"
directive to tell the assembler to start executing at that address right now. In other
words, you can assemble some code, execute it, then go back to assembling the rest of the
source text. Cute. Suppose you want to do something too hard for macros; just assemble
its input data, followed by some code to convert that into the form you want, then go back
to assembling more code. And that can start by backing up the assembly output pointer
("dot") so the conversion code doesn't actually take up space in the
finished program.
It sure makes cross-assemblers hard, because you have to include an EL-X8 simulator in
the assembler... :-)
paul
But at least it not a 386. Did any other computers have built in rom or
protected core used as rom for 'standard' routines like I/O or floating point.
Ben.
1047
days inactive
1048
days old
6 comments
4 participants
participants (4)
-
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
paulkoning＠comcast.net -
van.snyder＠sbcglobal.net