23 Jun
2021
23 Jun
'21
10:22 a.m.
Paul K got it right:
"Any language can be interpreted or compiled. For some languages, like
LISP and TECO, interpreting is a rather natural implementation techniques,
while for others (C, ALGOL) compilation is the obvious answer. But either
is possible."
A few quick notes...
Back around 1973, I wrote a compiler for InterLISP on the Burroughs B6700,
with the target code being a new P-code invented just for LISP (by, I
think, Bill Gord, based on Peter Deutsch and Ken Bowles P-code work).
Yeah, some parts of the P-code machine had to invoke the interpreter, but
that's philosophically no different than the next note...
Around 1977/1978, Hewlett-Packard released the source code for their COBOL
compiler for the HP 3000. My friend looked at the source and said: every
statement compiles into a bunch of subroutine calls!
So, technically....it was a compiler. But, essentially no machine code was
emitted :)
In 1984, HP announced their PA-RISC systems (HP 3000 and HP 9000), and that
their ALGOL-like language, SPL, used by them and customers on the HP 3000,
would not be ported to PA-RISC (because "it wasn't possible").
We looked at it and said: we can.
And, we did (without the "subroutine call" mechanism :)
In some cases, we emulate a 16-bit wide CISC architecture (e.g., if you use
the SPL construct "ASSEMBLE (...)", we compile it...into PA-RISC code
emulating the old architecture). It's still in use today, and can now emit
either PA-RISC code or C source code (for a form of cross-compiling).
What HP missed, and many people miss, is that any language can be
compiled. The main question one might ask is the degree of closeness to
machine code that's emitted :)
Stan
23 Jun
23 Jun
10:36 a.m.
On Jun 23, 2021, at 1:22 PM, Stan Sieler via cctalk
<cctalk at classiccmp.org> wrote:
Paul K got it right:
"Any language can be interpreted or compiled. For some languages, like
LISP and TECO, interpreting is a rather natural implementation techniques,
while for others (C, ALGOL) compilation is the obvious answer. But either
is possible."
A few quick notes...
...In some cases, we emulate a 16-bit wide CISC architecture (e.g., if you use
the SPL construct "ASSEMBLE (...)", we compile it...into PA-RISC code
emulating the old architecture). It's still in use today, and can now emit
either PA-RISC code or C source code (for a form of cross-compiling).
That's a bit like the machine code translation pioneered by DEC (MIPS to ALPHA) and
subsequently used by Apple ("Rosetta") for PowerPC to Intel and now Intel to ARM
(M1). In a sense, those translators are compilers like all others, except for the rather
unusual "source code" they accept as input. Similar but somewhat different: the
DEC Alpha assembler was a compiler front end, connected to the code generator shared with
the (conventional) Alpha compilers. It was rather amusing to say
"macro/optimize" and see what the optimizer would do to your assembly code...
What HP missed, and many people miss, is that any
language can be
compiled. The main question one might ask is the degree of closeness to
machine code that's emitted :)
I think it was Dijkstra who observed, in the context of the original EL-X1 compiler, that
you're generating code for a "machine" of your choosing. When you see a
runtime library call, it makes sense to think of that as a machine operation of a
hypothetical machine different from the physical target hardware. And function calls can
be encoded as subroutine jump instructions, or in what is often more compact and nearly as
fast, threaded code or P-code words. Typical FORTH implementations are neat in that
respect, since they use a threaded code encoding that allows for fast and efficient
switching between threaded code (subroutine calls) and straight machine code.
11:42 a.m.
On Wed, 2021-06-23 at 13:36 -0400, Paul Koning via cctalk wrote:
Typical FORTH implementations are neat in that
respect, since they
use a threaded code encoding that allows for fast and efficient
switching between threaded code (subroutine calls) and straight
machine code.
I have a vague recollection of a story about a FORTH processor that put
the addresses of the functions to be executed on the return-address
stack (68000?) and then executed a RETURN instruction.
2:09 p.m.
On Wed, Jun 23, 2021 at 11:42:22AM -0700, Van Snyder via cctalk wrote:
[...]
I have a vague recollection of a story about a FORTH
processor that put
the addresses of the functions to be executed on the return-address stack
(68000?) and then executed a RETURN instruction.
I was initially going to say that doesn't sound right because m68k's JMP
instruction supports all useful EA modes and a PEA/RTS combination takes two
extra bytes and is slower than a plain JMP. But pushing *many* return
addresses is more plausible because each function will then magically call
each other in turn. I'm still not entirely convinced it'd be enough of a win
(if any) over a conventional run of JSR instructions. Perhaps it actually
misused RTM, which I never quite understood because Motorola's documentation
on modules is rather opaque and it's only available on the 68020 onwards.
This wheeze works on x86 too--and of course most other CPUs--but it can make
mincemeat of performance on (some) modern CPUs because caches assume that
CALL and RET are paired.
ROP (https://en.wikipedia.org/wiki/Return-oriented_programming) is an
interesting application of this technique, usually for nefarious purposes.
4:50 p.m.
How you'd do such in Forth depends on the threading method. You have Indirect
threaded, direct threaded and call threaded. As you move to the right, they are faster and
easier to add optimization but harder to deal with some of the higher level operations
like Create Does> ( older Forth would be <Builds Does> ).
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Van Snyder via cctalk
<cctalk at classiccmp.org>
Sent: Wednesday, June 23, 2021 11:42 AM
To: cctalk at classiccmp.org <cctalk at classiccmp.org>
Subject: Re: On compiling. (Was a way off topic subject)
On Wed, 2021-06-23 at 13:36 -0400, Paul Koning via cctalk wrote:
Typical FORTH implementations are neat in that
respect, since they
use a threaded code encoding that allows for fast and efficient
switching between threaded code (subroutine calls) and straight
machine code.
I have a vague recollection of a story about a FORTH processor that put
the addresses of the functions to be executed on the return-address
stack (68000?) and then executed a RETURN instruction.
25 Jun
25 Jun
12:14 a.m.
On Wed, 23 Jun 2021, Van Snyder via cctalk wrote:
On Wed, 2021-06-23 at 13:36 -0400, Paul Koning via
cctalk wrote:
I saw this on the 6502 in Woz's Sweet-16 interpreter.
see e.g.
http://www.6502.org/source/interpreters/sweet16.htm#When_is_an_RTS_really_a…
I initialiy used this "trick" in my own little bytecode VM but it's
somewhat slower than some other methods, but as usual the trade-off is
code-size vs. speed...
Gordon
Typical FORTH implementations are neat in that
respect, since they
use a threaded code encoding that allows for fast and efficient
switching between threaded code (subroutine calls) and straight
machine code.
I have a vague recollection of a story about a FORTH processor that put
the addresses of the functions to be executed on the return-address
stack (68000?) and then executed a RETURN instruction. 
3:31 a.m.
On Jun 25, 2021, at 4:54 AM, Gordon Henderson via
cctalk <cctalk at classiccmp.org> wrote:
?On Wed, 23 Jun 2021, Van Snyder via cctalk wrote:
I saw this on the 6502 in Woz's Sweet-16 interpreter.
see e.g.
http://www.6502.org/source/interpreters/sweet16.htm#When_is_an_RTS_really_a…
I initialiy used this "trick" in my own little bytecode VM but it's
somewhat slower than some other methods, but as usual the trade-off is code-size vs.
speed...
Gordon
yeah standard 6502 trick to keep a jump table.
kelly
On Wed,
2021-06-23 at 13:36 -0400, Paul Koning via cctalk wrote:
Typical FORTH implementations are neat in that respect, since they
use a threaded code encoding that allows for fast and efficient
switching between threaded code (subroutine calls) and straight
machine code.
I have a vague recollection of a story about a FORTH processor that put
the addresses of the functions to be executed on the return-address
stack (68000?) and then executed a RETURN instruction. 
3:04 p.m.
On 6/25/21 3:31 AM, Kelly Fergason via cctalk wrote:
> On Jun 25, 2021, at 4:54 AM, Gordon Henderson via
cctalk <cctalk at classiccmp.org> wrote:
>
> http://www.6502.org/source/interpreters/sweet16.htm#When_is_an_RTS_really_a…
>
> I initialiy used this "trick" in my own little bytecode VM but it's
somewhat slower than some other methods, but as usual the trade-off is code-size vs.
speed...
This "trick" can be performed on nearly any microprocessor with a stack
that keeps return addresses on said stack--and permits a program to push
data onto the stack. Certainly x80 and x86 CPUs, where it isn't that
uncommon.
Interesting status returns can be implemented by adjusting the return
address on the stack in sort of a "reverse" computed goto; e.g.
sub_entry:....
add [stack top], status*jump instruction size
return
...calling code...
call sub_entry
jmp status_0
jmp status_1
jmp status_2
..etc.
Which saves the caller from having to perform multiple compares (or a
computed GOTO) on the status return.
On lower PIC microcontrollers, there is no way for a program to access
code space (i.e. Harvard architecture). Static lookup tables represent
a concept requiring some thought. Low PIC code memory uses 13 bit
words, while data memory uses 8. Fortunately, there is an opcode,
RETLW, that is "return from subroutine with 8 bit value in the W
register". So one codes a table of RETLW xx instructions and performs
an indexed call into it.
--Chuck
23 Jun
23 Jun
11:44 a.m.
There are the languages that are otherwise nearly impossible to compile.
Consider SNOBOL4 (although there is a compiled version called SPITBOL,
but without several hard-to-implement features). One can construct
statements at run time and execute them. A bit unusual back then, but
not so much today.
In a way, I'm a bit surprised that no version of BASIC (in my
experience) ever implemented this.
--Chuck
11:59 a.m.
On Jun 23, 2021, at 2:44 PM, Chuck Guzis via cctalk
<cctalk at classiccmp.org> wrote:
There are the languages that are otherwise nearly impossible to compile.
Consider SNOBOL4 (although there is a compiled version called SPITBOL,
but without several hard-to-implement features). One can construct
statements at run time and execute them. A bit unusual back then, but
not so much today.
That just means compiling it at the time the constructed statement is submitted for
execution, then executing the generated code. No problem so long as the compiler is
available at run time. PDP-10 TECO did that (it has the same feature, executing a string
buffer full of commands). So does Python, and I suspect it solves it the same way.
paul
1043
days inactive
1045
days old
9 comments
8 participants
participants (8)
-
abuse＠cabal.org.uk -
cclist＠sydex.com -
dkelvey＠hotmail.com -
gordon+cctalk＠drogon.net -
kfergason＠gmail.com -
paulkoning＠comcast.net -
sieler＠allegro.com -
van.snyder＠sbcglobal.net