On 6/25/21 3:31 AM, Kelly Fergason via cctalk wrote:
>> On Jun 25, 2021, at 4:54 AM, Gordon Henderson via cctalk
>> wrote:
>>
>> http://www.6502.org/source/interpreters/sweet16.htm#When_is_an_RTS_really_a_JSR_
>>
>> I initialiy used this "trick" in my own little bytecode VM but it's somewhat
>
> On Jun 25, 2021, at 4:54 AM, Gordon Henderson via cctalk
> wrote:
>
> On Wed, 23 Jun 2021, Van Snyder via cctalk wrote:
>
>>> 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 enc
On Wed, 23 Jun 2021, Van Snyder via cctalk wrote:
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
> On Jun 24, 2021, at 1:02 AM, ben via cctalk wrote:
>
> 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
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
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
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
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 applica
th would be
).
Dwight
From: cctalk on behalf of Van Snyder via cctalk
Sent: Wednesday, June 23, 2021 11:42 AM
To: cctalk@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:
&
> On Jun 23, 2021, at 5:02 PM, Chuck Guzis wrote:
>
> 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 co
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 goin
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 chang
> On Jun 23, 2021, at 2:44 PM, Chuck Guzis via cctalk
> 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
> state
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 toda
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 r
> On Jun 23, 2021, at 1:22 PM, Stan Sieler via cctalk
> 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 obvio
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
17 matches
Mail list logo
