I have long had a gut feel that the ability to algebraic
refactoring/rewriting/simplification of programs is a killer feature of
Joy / concatenative languages.
I just noted an practical application for this...
Out here in the embedded computing world there is a vast body of Legacy
assembler applications which cannot be ported to new CPU's as the old
parts go obselete.
So how about this for a solution....
Write in a concatenative language of your choice fragments that exactly
duplicate each machine instruction.
"assemble" the assembler source into the concatenative language.
Algebraically simplify as much as possible. (Quite like to something
even simpler than the original source!)
Compile the concatenative language to new CPU.
Done.
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@...
New Zealand
Carter's Clarification of Murphy's Law.
"Things only ever go right so that they may go more spectacularly wrong later."
From this principle, all of life and physics may be deduced.
This in an excellent idea! I really hope this will be possible some time
soon with Cat. Have you taken a look at the slides at
http://www.cdiggins.com/cat/cat.pdf ? I think it would be ideally suited for
this, though the language isn't quite ready.
On 8/3/06, John Carter <john.carter@...> wrote:
>
> I have long had a gut feel that the ability to algebraic
> refactoring/rewriting/simplification of programs is a killer feature of
> Joy / concatenative languages.
>
> I just noted an practical application for this...
>
> Out here in the embedded computing world there is a vast body of Legacy
> assembler applications which cannot be ported to new CPU's as the old
> parts go obselete.
>
> So how about this for a solution....
>
> Write in a concatenative language of your choice fragments that exactly
> duplicate each machine instruction.
>
> "assemble" the assembler source into the concatenative language.
>
> Algebraically simplify as much as possible. (Quite like to something
> even simpler than the original source!)
>
> Compile the concatenative language to new CPU.
>
> Done.
>
> John Carter Phone : (64)(3) 358 6639
> Tait Electronics Fax : (64)(3) 359 4632
> PO Box 1645 Christchurch Email : john.carter@...<john.carter%40tait.co.nz>
> New Zealand
>
> Carter's Clarification of Murphy's Law.
>
> "Things only ever go right so that they may go more spectacularly wrong
> later."
>
> From this principle, all of life and physics may be deduced.
>
>
[Non-text portions of this message have been removed]
> Write in a concatenative language of your choice fragments that exactlyI was planning to do something similar with my space invaders emulator
> duplicate each machine instruction.
written in Factor.
The instruction set in the emulator is actually defined declaratively:
INSTRUCTION: RET NZ ; opcode C0 cycles 05
INSTRUCTION: POP BC ; opcode C1 cycles 10
INSTRUCTION: JP NZ,nn ; opcode C2 cycles 10
INSTRUCTION: JP nn ; opcode C3 cycles 10
INSTRUCTION: CALL NZ,nn ; opcode C4 cycles 11
At parse time this is used to actually generate the Factor source for
the instructions buy using a pattern matcher for instruction
families:
{ "JP-NN" [ [ cpu-pc ] keep [ read-word ] keep set-cpu-pc ] }
{ "JP-(RR)" [ [ $1 ] keep set-cpu-pc ] }
{ "CALL-NN" [ (emulate-CALL) ] }
{ "LD-RR,NN" [ [ next-word ] keep $2 ] }
{ "LD-RR,RR" [ [ $3 ] keep $2 ] }
The $1,$2,$3, etc are replaced by the code to set/get cpu registers
depending on what was used in the INSTRUCTION: statement.
The end result is compiled factor code to emulate all the instructions.
It would be an interesting project to jit compile or ahead of time
compile the 8080 instructions to Factor code and run that.
The original plan was not not only generate the emulator instruction
words, but also to generate disassembler and assembler instructions to
provide an 8080 development environment in Factor. I never quite got
around to it though - too much time actually playing Space Invaders
once I got it running I think!
The code for the 8080 emulator portion is here:
http://www.bluishcoder.co.nz/repos/factor/Factor/contrib/space-invaders/cpu-8080.factor
It can be run in the current 'darcs' version of factor by doing:
"space-invaders" require
USE: space-invaders
run
Chris.
--
http://www.bluishcoder.co.nz
The same thing occurred to me when I first started playing with Joy,
and my own concat languages. There are a few applications I had in mind:
1. As a compiler target for general purpose programming languages. I
wondered if a concatenative language might be simple enough to ease
the implementation of a global optimiser yet expressive enough to
retain all the high level information which would be lost to a
canonical p-code optimiser.
2. As an extension of 1, a source code level optimiser whereby the
"shape" of the original source code is retained during manipulation so
that the optimised (or refactored if you like) version is returned to
the original source language in a recognisable form.
3. As an extension of 2, a general purpose aspect weaver where the
aspects are all compiled down to a concatenative language, woven and
returned to the original source language for examination, compilation
and source level debugging using the normal dev tools.
Sadly I've not had the time to pursue any of these although I'm aware
that a company local to me had also thought about 2 and intended to
try something similar. Not sure how far they got.
I've yet to be convinced that concatenative languages are good for
general purpose programming by humans. I know there is a sizable body
of Forth programmers but I suspect they're the deviants, not the pack
leaders in this context.
--- In concatenative@yahoogroups.com, John Carter <john.carter@...> wrote:
>
> I have long had a gut feel that the ability to algebraic
> refactoring/rewriting/simplification of programs is a killer feature
> of Joy / concatenative languages.
>
> I just noted an practical application for this...
>
> Out here in the embedded computing world there is a vast body of
> Legacy assembler applications which cannot be ported to new CPU's as
> the old parts go obselete.
>
> So how about this for a solution....
>
> Write in a concatenative language of your choice fragments that
> exactly duplicate each machine instruction.
>
> "assemble" the assembler source into the concatenative language.
>
> Algebraically simplify as much as possible. (Quite like to something
> even simpler than the original source!)
>
> Compile the concatenative language to new CPU.
>
> Done.
Martin Young <martin@...> wrote:
> I've yet to be convinced that concatenative languages are good forPurely anecdotal evidence is that people who get into Forth and a pure
> general purpose programming by humans.
functional language report similar positive subjective experiences
between the two. Forth, in spite of its extremely low-level and
non-theoretical background, FEELS like a highly designed language. I
know Chuck Moore is a genius :-), but I think this is more due to
concatenativity than it is to clean language design (doubly so because
most Forth is written using the ANS Forth dialect, which was designed
by a committee).
So I suspect that they ARE good for general purpose use by humans. I'm
sure that for some uses they're inferior, of course, but again, I'm
speaking in general. (I'm not claiming that non-concatenative
languages are bad, or even less good; I'm not making any relative
examinations, really.)
> I know there is a sizable bodyYa, I don't even know how sizable the number of Forth programmers is.
> of Forth programmers but I suspect they're the deviants, not the pack
> leaders in this context.
I do believe there are more non-programmers who use Forth than there
are programmers: engineers, technicians, scientists, etc.
I suspect the reasons for this include the total lack of computer
science knowledge about Forthlike languages. This suspicion of mine is
one reason I've been happy to see the progress in the study of
concatenative languages.
By the way, Chuck Moore helped start and is working on a new company
now: Intellasys (www.intellasys.net). Interesting extremely low power,
high speed 24-core CPUs, with each core running at about 1GHz (and for
a change, including a multiply instruction). They run something like
machineForth, of course. I haven't managed to get the details yet on
the language. There's definitely one new thing that's been missing in
Forth: libraries (he calls them 'forthlets').
-Billy