PAF: a Portable Assembly Language

[Aliaksei Chapyzhenka]

Hi All,

I have discovered great paper from Anton Ertl about Forth based Portable Assembly Language (PAF):

http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/ertl-paf.pdf

I plan using it in the tool chain for my processor project, and was looking for more information about PAF. Does anybody can help me with:
PAF wordlist?
any open source PAF reference implementation?
any other papers, threads, information sources?

--Alexey

[hughag...@gmail.com]

This has already been discussed in this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/YVjtNQwSIH0%5B326-350-false%5D
Is that where you discovered it? Anton Ertl's paper isn't "great" --- I read the abstract, but didn't consider the paper worth reading.

Anton thinks that the register set size can be abstracted away, but this isn't true, as that is the one aspect of the target processor that has to be standardized. I don't think that Anton knows enough about assembly language to be the person who designs this portable-assembler.

The idea of a portable assembler is good, as this would allow Forth to be quickly ported to any processor that fits the basic profile (there is not much difference between the MIPS, ARM and ColdFire, for example) --- all that would be needed would be to rewrite the portable-assembler, and then the Forth system program would assemble for a new processor --- but the target processors have to be similar in that they all have the minimum number of registers and a reasonably orthogonal instruction set (there is a lot of difference between the 6502 and the Z80, or between the 6812 and the 8086, so a portable assembler wasn't realistic for them).

This is what I said in the thread mentioned previously:
On Tuesday, January 20, 2015 at 9:40:31 PM UTC-7, hughag...@gmail.com wrote:
> This is a good idea. This idea has been around since the 1980s though, so you shouldn't take credit for it.
>
> You can't abstract away the register set size --- you have to assume a certain number of registers. This is why the idea is feasible now, and wasn't feasible in the 1980s --- because you can assume 16 registers now (this leaves out the 32-bit x86 though, but it is obsolete anyway) --- in the old days, processors had very few registers, and juggling these few registers was different on every processor (the 6812 and the 8086, for example).
>
> Your PAF won't work on the MiniForth though --- it will only work on mainstream processors.
>
> Anyway, what I'm doing right now is targeting the 8-bit AVR. This is the smallest processor that I can imagine my Forth running on (16 registers with 3 that can be used as pointers) --- porting it to a larger more powerful processor should be easy (although going in the other direction, from a powerful processor to a more limited one, would be difficult). I don't actually consider the AVR to be very useful, because it is not powerful enough for most applications and it is well on its way to being obsolete --- I am just interested in the AVR as a proof-of-concept platform.

[Paul E Bennett]

There was an article in Forthwrite about the MAF and PAF implementations and
maybe also mentioned in Forth Dimensions. The Forthwrite on-line resource
didn't manage to get all the early paper versions scanned and on-line but I
have many of the missing ones in my library. An email to Graham Dunbar might
also be worthwhile.

--
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E....@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[Aliaksei Chapyzhenka]

Thank you for the responses. I have seen these brief mentions of the topic. My inquiry was rather to find any current activity of the subject. I found PAF being quite attractive target for my JavaScript transcompiler project.

Some things I am missing (based on brief PAF description) and wanted to reconcile with PAF philosophy are: PICK for arbitrary or limited depth; Control structures like: begin-while-repeat, do-loop may come handy too.

One way or another I like the idea of PAF and wanted to harmonize with confederates.

--Alexey

[Anton Ertl]

For now this is just an idea. There are no implementations yet.
There is another version of the same paper
<http://www.complang.tuwien.ac.at/papers/ertl-kps13.ps.gz>, but I
recommend the version you linked to.

Not sure what you have in mind with "PAF wordlist"; implementing PAF
on top of Forth is mostly trivial (it is mostly Forth, after all), but

1) There are a few features that would be quite a bit of work: ABI
definitions and ABI calls, labels and gotos.

2) The entire point of PAF is to get rid of separate stacks and
separate stack pointers, to allow to put all stack items in registers
that fit, and use a common stack for the spilled stack items.
Implementing PAF on top of a conventional Forth would not achieve that
objective.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/

[Anton Ertl]

Aliaksei Chapyzhenka <alex...@gmail.com> writes:
>Some things I am missing (based on brief PAF description) and wanted to reconcile with PAF philosophy are: PICK for arbitrary or limited depth;

The parameter of PICK has to be a constant or otherwise its value must
be statically determined in order to keep the stack accesses
statically determinable.

> Control structures like: begin-while-repeat, do-loop may come handy too.

They can be built without problems from begin again until ahead if
then cs-roll, plus some arithmetics and return stack stuff for
do-loop.

Concerning Forthwrite, if there was a PAF in early Forthwrite, it's
something other than the PAF that this thread is about (first
published in 2013).

[Aliaksei Chapyzhenka]

> Not sure what you have in mind with "PAF wordlist"; implementing PAF
> on top of Forth is mostly trivial (it is mostly Forth, after all), but
>
> 1) There are a few features that would be quite a bit of work: ABI
> definitions and ABI calls, labels and gotos.
>
> 2) The entire point of PAF is to get rid of separate stacks and
> separate stack pointers, to allow to put all stack items in registers
> that fit, and use a common stack for the spilled stack items.
> Implementing PAF on top of a conventional Forth would not achieve that
> objective.

Most assemblers that I know have fixed set of mnemonics and optionally a macro-instruction facility. So some other compiler would have a clear target. I was thinking that it worth maintaining a clear core list of words that every PAF back-end would know; end every high level language compiler can target.
The statement: "implementing PAF on top of Forth is mostly trivial" makes PAF even more amorphous then Forth. May not be the best approach for retargetable assembler language.

--Alexey

[Aliaksei Chapyzhenka]

On Sunday, January 25, 2015 at 7:17:45 AM UTC-8, Anton Ertl wrote:
> For now this is just an idea. There are no implementations yet.

The good one. I am implementing JavaScript to PAF front-end right now and will do the back end for my stack-oriented processor later.

[Aliaksei Chapyzhenka]

On Sunday, January 25, 2015 at 7:36:06 AM UTC-8, Anton Ertl wrote:
> The parameter of PICK has to be a constant or otherwise its value must
> be statically determined in order to keep the stack accesses
> statically determinable.

Awesome, it would help a lot building compiler front-end.

[hughag...@gmail.com]

On Sunday, January 25, 2015 at 8:17:45 AM UTC-7, Anton Ertl wrote:
> For now this is just an idea. There are no implementations yet.

> ... implementing PAF on top of Forth is mostly trivial

How do you know that it is trivial if you haven't done it?

This reminds me a lot of how the ANS-Forth standard was written in stone, without benefit of a reference compiler, so it was never tested until many years later.

> 2) The entire point of PAF is to get rid of separate stacks and
> separate stack pointers, to allow to put all stack items in registers
> that fit, and use a common stack for the spilled stack items.
> Implementing PAF on top of a conventional Forth would not achieve that
> objective.

You are going to have one common stack to handle spill-over for multiple stacks? WTF??? This doesn't sound trivial, or even possible.

If you want a "portable assembly-language" for 32-bit micro-controllers, why don't you just go with ARM-Cortex like everybody else in the world? In the 32-bit micro-controller world, the ARM is used in maybe 99% of all applications. In the desktop-computer world, the 64-bit x86 is pretty close to 100%. Both the ARM and the 64-bit x86 have 16 registers (the MIPS, ColdFire, etc. too) --- it is realistic to assume 16 registers.

This whole PAF thing that "abstracts away register set size" seems like an academic exercise with little or no connection to reality (by "reality" I mean motion-control boards, and such things that do something useful that people pay money for). Your Gforth had no connection to reality either, as it is way to slow for real-time, and real-time is what micro-controllers do. PAF and Gforth are just overgrown science-fair projects. Have fun! Resign from the Forth-200x committee however, as you can't claim to be a leader when you are totally disconnected from real-world work.

[Aliaksei Chapyzhenka]

On Sunday, January 25, 2015 at 7:17:45 AM UTC-8, Anton Ertl wrote:
> For now this is just an idea. There are no implementations yet.

Anton,
In section 3.6 Memory. You have variety of load/store words:
( sc@ w@ l@ sf@ df@ c@ uw@ ul@ @ )( c! w! l! sf! df! ! )

Does it make sense to use LLVM-ish cell size notation? like:

( i8@ i16@ i32@ i64@ f32@ f64@ u8@ u16@ u32@ @ ) ( i8! i16! i32! f32! f64! ! )

Well I have improvised a bit with u??@ prefix, I confess.

--Alexey

[Paul E Bennett]

Anton Ertl wrote:

[%X]

> Concerning Forthwrite, if there was a PAF in early Forthwrite, it's
> something other than the PAF that this thread is about (first
> published in 2013).

In which case, you are right. I just remembered seeing the articles in
Forthwrite (before 2013). So, sam name but different item.

[Anton Ertl]

Aliaksei Chapyzhenka <alex...@gmail.com> writes:
>> Not sure what you have in mind with "PAF wordlist"; implementing PAF
>> on top of Forth is mostly trivial (it is mostly Forth, after all), but

>>=20

>> 1) There are a few features that would be quite a bit of work: ABI
>> definitions and ABI calls, labels and gotos.

>>=20

>> 2) The entire point of PAF is to get rid of separate stacks and
>> separate stack pointers, to allow to put all stack items in registers
>> that fit, and use a common stack for the spilled stack items.
>> Implementing PAF on top of a conventional Forth would not achieve that
>> objective.
>

>Most assemblers that I know have fixed set of mnemonics and optionally a ma=
>cro-instruction facility. So some other compiler would have a clear target.=
> I was thinking that it worth maintaining a clear core list of words that e=
>very PAF back-end would know; end every high level language compiler can ta=
>rget.

Certainly, once PAF is implemented, it will have a fixed set of words,
and a macro facility derived from Forth. But for now it's not
completely specified, and casting a specification in stone before
implementing it would be a bad idea: it's too easy to overlook
something important.

[Anton Ertl]

hughag...@gmail.com writes:
>On Sunday, January 25, 2015 at 8:17:45 AM UTC-7, Anton Ertl wrote:
>> 2) The entire point of PAF is to get rid of separate stacks and
>> separate stack pointers, to allow to put all stack items in registers
>> that fit, and use a common stack for the spilled stack items.
>> Implementing PAF on top of a conventional Forth would not achieve that
>> objective.
>

>You are going to have one common stack to handle spill-over for multiple st=

>acks? WTF??? This doesn't sound trivial, or even possible.

Right, it's not trivial. It took me many years to find out which
features of Forth are incompatible with this idea; these features are
absent from PAF, and that makes it possible.

[Anton Ertl]

Aliaksei Chapyzhenka <alex...@gmail.com> writes:
>On Sunday, January 25, 2015 at 7:17:45 AM UTC-8, Anton Ertl wrote:
>> For now this is just an idea. There are no implementations yet.
>
>Anton,
>In section 3.6 Memory. You have variety of load/store words:
>( sc@ w@ l@ sf@ df@ c@ uw@ ul@ @ )( c! w! l! sf! df! ! )
>
>Does it make sense to use LLVM-ish cell size notation? like:
>
>( i8@ i16@ i32@ i64@ f32@ f64@ u8@ u16@ u32@ @ ) ( i8! i16! i32! f32! f64! ! )

It's just names, so one can choose either. The names I suggested are
in line with Forth usage. The names you suggest are probably easier
on non-Forthers.

[hughag...@gmail.com]

On Monday, January 26, 2015 at 5:25:02 AM UTC-7, Anton Ertl wrote:
> hughag...@gmail.com writes:
> >On Sunday, January 25, 2015 at 8:17:45 AM UTC-7, Anton Ertl wrote:
> >> 2) The entire point of PAF is to get rid of separate stacks and
> >> separate stack pointers, to allow to put all stack items in registers
> >> that fit, and use a common stack for the spilled stack items.
> >> Implementing PAF on top of a conventional Forth would not achieve that
> >> objective.
> >
> >You are going to have one common stack to handle spill-over for multiple st=
> >acks? WTF??? This doesn't sound trivial, or even possible.
>
> Right, it's not trivial. It took me many years to find out which
> features of Forth are incompatible with this idea; these features are
> absent from PAF, and that makes it possible.

20 years ago, Forth seemed straightforward and obvious to me --- the point was to build useful boards --- Forthers got paid to do this. When I worked at Testra, the goal was to build an improved motion-control board, as the previous one (Dallas 80c320) was too slow. AFAIK, none of the customers knew that Forth was being used, or would have cared --- it was all about performance --- the MiniForth significantly outperformed the competitor's board, and cost less (I think the competitor was using a 68K programmed in C, although I never saw their stuff).

I'm extremely frustrated because I think that the Forth leadership has lost their way. Your Gforth is not about performance; two decades after the MiniForth, you aren't even in the ballpark yet. Gforth was written in GCC to make it portable, but this assumes that GCC is portable everywhere, which is not true (GCC is only portable to processors with a C-style locals' frame). Also, portability for Gforth is meaningless anyway because nobody is using Gforth (too slow) and so no programs are getting ported because there aren't any programs. Now you have this PAF that seems highly speculative as to whether it will actually work, or if the language will still be Forth after it has been contorted enough to make it work --- you believe that the point is portability --- but portability was solved years ago when everybody standardized on the 64-bit x86 (for desktop-computers) and ARM (for micro-controllers), so you are solving a problem that has already been solved.

The point is performance. Nobody is going to take the Forth community seriously until the leadership stops dinking around with these muddle-headed overly-complicated zero-practicality toys. Both ANS-Forth and Gforth need to be scrapped! Start over! Write a dual-Forth system (desktop-computer version in 64-bit x86 and micro-controller version in ARM) and make sure that it provides adequate performance to compete against C --- you have lost your way --- this is how you get back on the path.

Associating with Elizabeth Rather and writing a performance Forth are mutually exclusive --- you can't do both.

[Aliaksei Chapyzhenka]

On Monday, January 26, 2015 at 4:09:41 AM UTC-8, Anton Ertl wrote:
> Certainly, once PAF is implemented, it will have a fixed set of words,
> and a macro facility derived from Forth. But for now it's not
> completely specified, and casting a specification in stone before
> implementing it would be a bad idea: it's too easy to overlook
> something important.

Agree, no point fixing it now. I think RISC-V would be good reference target for the PAF. I am working on Stack-based processor using and porting PAF to it.
--Alexey

[Anton Ertl]

Aliaksei Chapyzhenka <alex...@gmail.com> writes:
>I think RISC-V would be good reference target for the PAF.

While the goals of RISC-V are laudable, with its current lack of
popularity PAF for RISC-V would be a minority language on a minority
architecture, with an expected user base of <1 user. The plan is to
start with AMD64.

> I am working on Stack-based processor using and porting PAF to it.

Great. Note that the restrictions of PAF are designed for
implementations on register machines and may be unnecessary on stack
machines.