Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #60523 > unrolled thread

Portable Assembler

Back to article view | Back to comp.lang.forth

Contents

  Portable Assembler rickman <gnuarm@gmail.com> - 2017-06-09 14:35 -0400
    Portable Assembler Mark Wills <markwills1970@gmail.com> - 2017-06-09 11:47 -0700
      Re: Portable Assembler rickman <gnuarm@gmail.com> - 2017-06-09 15:30 -0400
        Re: Portable Assembler Cecil Bayona <cbayona@cbayona.com> - 2017-06-09 15:51 -0500
          Re: Portable Assembler rickman <gnuarm@gmail.com> - 2017-06-09 18:13 -0400
            Re: Portable Assembler foxaudioresearch@gmail.com - 2017-06-09 15:23 -0700
              Re: Portable Assembler Cecil Bayona <cbayona@cbayona.com> - 2017-06-09 20:34 -0500
                Re: Portable Assembler albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-10 08:36 +0200
                  Re: Portable Assembler Cecil Bayona <cbayona@cbayona.com> - 2017-06-10 10:31 -0500
                    Re: Portable Assembler Mark Wills <markwills1970@gmail.com> - 2017-06-11 09:07 -0700
                      Re: Portable Assembler rickman <gnuarm@gmail.com> - 2017-06-11 12:36 -0400
                      Re: Portable Assembler Cecil Bayona <cbayona@cbayona.com> - 2017-06-11 11:40 -0500
                        Re: Portable Assembler Mark Wills <markwills1970@gmail.com> - 2017-06-12 05:30 -0700
                          Re: Portable Assembler Mark Wills <markwills1970@gmail.com> - 2017-06-21 02:49 -0700
                            Re: Portable Assembler foxaudioresearch@gmail.com - 2017-06-21 06:24 -0700
                          Re: Portable Assembler foxaudioresearch@gmail.com - 2017-06-20 17:42 -0700
                    Re: Portable Assembler albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-16 15:02 +0200
                      Re: Portable Assembler Alex <alex@rivadpm.com> - 2017-06-16 15:09 +0100
                        Re: Portable Assembler Cecil Bayona <cbayona@cbayona.com> - 2017-06-16 11:24 -0500
                          Re: Portable Assembler Alex <alex@rivadpm.com> - 2017-06-16 18:04 +0100
                            Re: Portable Assembler Alex <alex@rivadpm.com> - 2017-06-16 18:23 +0100
                Re: Portable Assembler Alex <alex@rivadpm.com> - 2017-06-10 11:34 +0100
                  Re: Portable Assembler Cecil Bayona <cbayona@cbayona.com> - 2017-06-10 10:57 -0500
                Re: Portable Assembler stephen@mpeforth.com (Stephen Pelc) - 2017-06-10 16:47 +0000
                  Re: Portable Assembler Cecil Bayona <cbayona@cbayona.com> - 2017-06-10 12:57 -0500
          Re: Portable Assembler David Schultz <abuse@127.0.0.1> - 2017-06-09 19:23 -0500
            Re: Portable Assembler Cecil Bayona <cbayona@cbayona.com> - 2017-06-09 20:21 -0500
              Re: Portable Assembler hughaguilar96@gmail.com - 2017-06-09 18:38 -0700
    Re: Portable Assembler Paul Rubin <no.email@nospam.invalid> - 2017-06-10 00:28 -0700
      Re: Portable Assembler rickman <gnuarm@gmail.com> - 2017-06-11 01:15 -0400

Page 2 of 2 — ← Prev page 1 [2]

#60839

On 6/16/2017 18:04, Alex wrote:
> 64bit? [if] ' *8 [else] ' *4 [then] constant *cell-scale
> 5 cells value offset
> 
> code x
>    mov word { offset ebx ecx *cell-scale } 20
>    ret
> end-code
> drop

No DROP, that's an error...

-- 
Alex

[toc] | [prev] | [next] | [standalone]

#60552

On 6/10/2017 02:34, Cecil Bayona wrote:
> On 6/9/2017 5:23 PM, foxaudioresearch@gmail.com wrote:
>> But Cecil has rediscovered the truth about assemblers in Forth.
>> They are not too difficult especially if you do not  try to get fancy.
>>
> 
> RPN assemblers are pretty simple in Forth but if one wants Infix 
> mnemonics its a little harder but not bad using Forth to create it. I 
> like the Infix mnemonics used by the VFX Forth by MPE but it requires 
> more work to do.
> 

There's a BSD licensed version of a postfix 32 and 64 bit Intel 
assembler as part of my WF32 project here; 
https://github.com/alextangent/wf32/tree/master/src/asm, documented at 
https://github.com/alextangent/wf32/blob/master/src/asm/readme.txt

I'm currently modifying the way its packaged to simplify porting between 
Forths, but the essence will be the same; there is an engine of about 
400 lines of code (lots of comments ups that to just under 1000) and 
then instruction tables at approx 1.<a small bit> lines per opcode 
(again, lots of comments push the figure higher). The assembler 
currently takes up 57KB of code and data space once loaded.

The engine can generate most (no VEX currently and no 16 bit 
contemplated) instructions from supplied tables for 32 bit and 64 bit 
modes.

The opcode tables support basic instructions, floats and (a few) SSE 
instructions. Support macros for specific Forths (like NEXT and labels) 
are provided in a separate file to aid porting.

The disassembler is a work in progress, but disassembles the basic 
instruction set OK. No floats or SSE/VEX stuff yet.

The syntax is Intel, with one modification; instead of [ ] to indicate 
memory operands, { } are used. So Intel [EAX][EBX] becomes { EAX EBX }.
Here's an example (the disassembler produces code that can be 
assembled). There's no clash with { } locals syntax as the assembler 
runs while interpreting.

code c@  ( a1 -- c1 )    \ fetch the character c1 from address a1
       movzx   eax byte { eax }
       next; inline

see c@ code c@ ( ? -- ? )
\ c@ is defined in src/kernel/gkernel32.fs at line 274
\ ' optc@ compiled
\ code=$401284 len=3 type=129
( $0 )    movzx   eax byte { eax }                  \ 0FB600
( $3 )    ret                                       \ C3 ( end ) ok

code ?dup       ( n -- n [n] )  \ duplicate top of data stack if non-zero
     1 -1 in/out
       test    eax eax
       je      short @@1
       mov     { -cell ebp } eax
       sub     ebp cell
@@1:  next; inline

see ?dup
code ?dup ( 1 -- ? )
\ ?dup is defined in src/kernel/gkernel32.fs at line 162
\ inlined
\ code=$401183 len=10 type=129
( $0 )    test    eax eax                           \ 85C0
( $2 )    je      short ' ?dup $A +                 \ 7406
( $4 )    mov     dword { $-4 ebp } eax             \ 8945FC
( $7 )    sub     ebp $4                            \ 83ED04
( $A )    ret                                       \ C3 ( end ) ok

-- 
Alex

[toc] | [prev] | [next] | [standalone]

#60565

On 6/10/2017 5:34 AM, Alex wrote:
> On 6/10/2017 02:34, Cecil Bayona wrote:
>> On 6/9/2017 5:23 PM, foxaudioresearch@gmail.com wrote:
>>> But Cecil has rediscovered the truth about assemblers in Forth.
>>> They are not too difficult especially if you do not  try to get fancy.
>>>
>>
>> RPN assemblers are pretty simple in Forth but if one wants Infix 
>> mnemonics its a little harder but not bad using Forth to create it. I 
>> like the Infix mnemonics used by the VFX Forth by MPE but it requires 
>> more work to do.
>>
> 
> There's a BSD licensed version of a postfix 32 and 64 bit Intel 
> assembler as part of my WF32 project here; 
> https://github.com/alextangent/wf32/tree/master/src/asm, documented at 
> https://github.com/alextangent/wf32/blob/master/src/asm/readme.txt
> 
> I'm currently modifying the way its packaged to simplify porting between 
> Forths, but the essence will be the same; there is an engine of about 
> 400 lines of code (lots of comments ups that to just under 1000) and 
> then instruction tables at approx 1.<a small bit> lines per opcode 
> (again, lots of comments push the figure higher). The assembler 
> currently takes up 57KB of code and data space once loaded.
> 
> The engine can generate most (no VEX currently and no 16 bit 
> contemplated) instructions from supplied tables for 32 bit and 64 bit 
> modes.
> 
> The opcode tables support basic instructions, floats and (a few) SSE 
> instructions. Support macros for specific Forths (like NEXT and labels) 
> are provided in a separate file to aid porting.
> 
> The disassembler is a work in progress, but disassembles the basic 
> instruction set OK. No floats or SSE/VEX stuff yet.
> 
> The syntax is Intel, with one modification; instead of [ ] to indicate 
> memory operands, { } are used. So Intel [EAX][EBX] becomes { EAX EBX }.
> Here's an example (the disassembler produces code that can be 
> assembled). There's no clash with { } locals syntax as the assembler 
> runs while interpreting.
> 
> code c@  ( a1 -- c1 )    \ fetch the character c1 from address a1
>        movzx   eax byte { eax }
>        next; inline
> 
> see c@ code c@ ( ? -- ? )
> \ c@ is defined in src/kernel/gkernel32.fs at line 274
> \ ' optc@ compiled
> \ code=$401284 len=3 type=129
> ( $0 )    movzx   eax byte { eax }                  \ 0FB600
> ( $3 )    ret                                       \ C3 ( end ) ok
> 
> code ?dup       ( n -- n [n] )  \ duplicate top of data stack if non-zero
>      1 -1 in/out
>        test    eax eax
>        je      short @@1
>        mov     { -cell ebp } eax
>        sub     ebp cell
> @@1:  next; inline
> 
> see ?dup
> code ?dup ( 1 -- ? )
> \ ?dup is defined in src/kernel/gkernel32.fs at line 162
> \ inlined
> \ code=$401183 len=10 type=129
> ( $0 )    test    eax eax                           \ 85C0
> ( $2 )    je      short ' ?dup $A +                 \ 7406
> ( $4 )    mov     dword { $-4 ebp } eax             \ 8945FC
> ( $7 )    sub     ebp $4                            \ 83ED04
> ( $A )    ret                                       \ C3 ( end ) ok
> 

That is big relatively speaking, I expect my RPN assembler when finished 
to be way under a hundred lines of code, most likely two but at most 
three pages of code. I'm assuming here that a Infix version would be 
twice as big, most likely not as fancy as this assembler but by keeping 
things simple it might be way under two hundred lines of code.

I see the need for a very simple assembler that uses the same mnemonics 
for several CPUs as a tool to cut down the effort when writing assembler 
code for several CPUs so a fancy feature set needs to take a back seat 
to simplicity. But by incrementally improving the assembler eventually 
one could have a decent set of features, the main goal will at all times 
be simplicity so that will limit  the features to an extent.

This has been a learning experience as well as a desire to have a simple 
set of tools, so there are bound to be a lot of detours in this journey. 
Writing this assembler is a detour in itself, I could have easily taken 
one of many available assemblers and modify it for my purposes but 
writing one from scratch is a learning experience and fun too.


-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#60569

On Fri, 9 Jun 2017 20:34:17 -0500, Cecil Bayona <cbayona@cbayona.com>
wrote:

>RPN assemblers are pretty simple in Forth but if one wants Infix 
>mnemonics its a little harder but not bad using Forth to create it. I 
>like the Infix mnemonics used by the VFX Forth by MPE but it requires 
>more work to do.

The idea was published in a FORML 1987 paper by Bob Smith. The one at
Asilomar. It's a truly glorious piece of code in a few lines. We have
expanded it a bit for portability but it lasted unchanged until 2002.

The code may be found in my EuroForth 2009 paper on Porting Forth
 http://www.complang.tuwien.ac.at/anton/euroforth/ef09/papers/pelc.pdf

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#60576

On 6/10/2017 11:47 AM, Stephen Pelc wrote:
> On Fri, 9 Jun 2017 20:34:17 -0500, Cecil Bayona <cbayona@cbayona.com>
> wrote:
> 
>> RPN assemblers are pretty simple in Forth but if one wants Infix
>> mnemonics its a little harder but not bad using Forth to create it. I
>> like the Infix mnemonics used by the VFX Forth by MPE but it requires
>> more work to do.
> 
> The idea was published in a FORML 1987 paper by Bob Smith. The one at
> Asilomar. It's a truly glorious piece of code in a few lines. We have
> expanded it a bit for portability but it lasted unchanged until 2002.
> 
> The code may be found in my EuroForth 2009 paper on Porting Forth
>   http://www.complang.tuwien.ac.at/anton/euroforth/ef09/papers/pelc.pdf
> 
> Stephen
> 
> 
Thanks for the references, I will look into it some. Google is not being 
cooperative in finding the 1987 FORML documents, I will try later today 
after lunch. All I can find are abstracts and a link to download the 
proceedings from the ACM but you have to be a member.

I thought of two ways of doing an Infix Assembler;
1. Delay generating code until the next opcode or eof or certain word 
shows up, then generate the code for the previous mnemonic.
2. Build words to search for the operands after the mnemonic is executed 
once found then generate the code.

After an extremely brief look at your paper it looks like the second 
case but I will look at the document in detail later today.

Anyone knows where to get the 1987 proceedings papers, Google is not 
much help.

Thanks

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#60537

On 06/09/2017 03:51 PM, Cecil Bayona wrote:
> I decided to create an assembler from scratch, and I have spent a couple
> of hours on it. It's for now printing the generated code to the screen
> so it's easier to check but a minor change to write it to a definition.

I wrote a MSP430 assembler for eForth and while it isn't fully tested I
did use it to write and test some code.

The basic MSP430 instructions aren't too difficult to deal with but the
CPUX extensions are more trouble. So far I have just implemented a few
that I needed.


-- 
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

[toc] | [prev] | [next] | [standalone]

#60538

On 6/9/2017 7:23 PM, David Schultz wrote:
> On 06/09/2017 03:51 PM, Cecil Bayona wrote:
>> I decided to create an assembler from scratch, and I have spent a couple
>> of hours on it. It's for now printing the generated code to the screen
>> so it's easier to check but a minor change to write it to a definition.
> 
> I wrote a MSP430 assembler for eForth and while it isn't fully tested I
> did use it to write and test some code.
> 
> The basic MSP430 instructions aren't too difficult to deal with but the
> CPUX extensions are more trouble. So far I have just implemented a few
> that I needed.
> 
> 

The MSP430 is very nice and after a couple of hours I have the 
beginnings of an assembler starting to work, most of the time has been 
spent on reading articles when I spend time on the project. Forth is 
really a good tool to generate an assembler, a good deal of the things 
needed is already inside Forth.

It's a low priority for me but eventually I would like eventually to get 
a version of the assembler/meta compiler to generate i386 code as there 
are not a whole lot of OSX forth compilers available, a lot of the 
available ones are offshoots of Forth, Forth like but not close to Forth.

As far as CPUs I'm more interested in devices like the MSP430, PIC24, 
PIC32, esp8266, and other embedded processors. I don't want to bother 
with ARM as I already have a few tools for ARM already. Right now the 
only decent Forth compile I have that I have available for the major 
OSes is SwiftForth as it comes with a Windows, Linux, and MacOS versions 
included so I will continue using it as a tool to create a Forth 
assembler/meta-compiler for those OSes.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#60540

On Friday, June 9, 2017 at 6:21:58 PM UTC-7, Cecil - k5nwa wrote:
> On 6/9/2017 7:23 PM, David Schultz wrote:
> > On 06/09/2017 03:51 PM, Cecil Bayona wrote:
> >> I decided to create an assembler from scratch, and I have spent a couple
> >> of hours on it. It's for now printing the generated code to the screen
> >> so it's easier to check but a minor change to write it to a definition.
> > 
> > I wrote a MSP430 assembler for eForth and while it isn't fully tested I
> > did use it to write and test some code.
> > 
> > The basic MSP430 instructions aren't too difficult to deal with but the
> > CPUX extensions are more trouble. So far I have just implemented a few
> > that I needed.
> 
> The MSP430 is very nice and after a couple of hours I have the 
> beginnings of an assembler starting to work, most of the time has been 
> spent on reading articles when I spend time on the project. Forth is 
> really a good tool to generate an assembler, a good deal of the things 
> needed is already inside Forth.

For the most part, I don't like CREATE DOES> --- for an assembler however, CREATE DOES> work very well!

If you wrote an assembler such as MACRO11 or MASM in an Algol-derived language, you would have to write code to parse the assembly-language source-code, which can be complicated. Also, you would have to write your own macro language, which can be complicated (that is why most assembler's macro language is very prickly and hard to use, such as in FASM).

In Forth, your outer interpreter does the parsing for you, and Forth itself is the macro language --- all in all, writing an assembler in Forth is significantly easier than in any Algol-derived language --- it might be comparably easy in Lisp, but I don't know enough about Lisp to comment on that.

[toc] | [prev] | [next] | [standalone]

#60545

rickman <gnuarm@gmail.com> writes:
> So what happened with the conversation of the forth written in
> portable assembler?  

Portable assemblers been done a bunch of times.  See the "prior work"
section of Anton's PAF paper, e.g. systems like Spitbol, GNU Lightning,
etc.  Dan Bernstein's qhasm is also something like that, geared to
exposing the non-portable features of particular architectures in
addition to abstracting the portable ones.

Maybe Figforth was written in something like that style.  I know 
Forth traditionally has had abstract names for registers, like W,
TOS, and so on.

[toc] | [prev] | [next] | [standalone]

#60598

Paul Rubin wrote on 6/10/2017 3:28 AM:
> rickman <gnuarm@gmail.com> writes:
>> So what happened with the conversation of the forth written in
>> portable assembler?
>
> Portable assemblers been done a bunch of times.  See the "prior work"
> section of Anton's PAF paper, e.g. systems like Spitbol, GNU Lightning,
> etc.  Dan Bernstein's qhasm is also something like that, geared to
> exposing the non-portable features of particular architectures in
> addition to abstracting the portable ones.
>
> Maybe Figforth was written in something like that style.  I know
> Forth traditionally has had abstract names for registers, like W,
> TOS, and so on.

How well do you think that would work on a CPU that is stack based with no 
registers, per se?

-- 

Rick C

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web