Forth-ish assemblers 
Author Message
 Forth-ish assemblers



Quote:
> Anyhow, I'm just looking for folks' experiences in writing nifty little
> assemblers in Forth.  The standard RPN assembler is certainly the
easiest,
> but does anyone really write serious code using that syntax?  I've done
> 'em both ways, RPN and "normal," but the latter always gets messy and
> seems to lose some of the nice advantages of Forth.  Actually, the RPN
> syntax works fine for single operand assembly languages, like 6502, but
> looks horrendously scary for a three-operand chip like the PowerPC.

I've written many assemblers in Forth over the years, including some for
three operand instruction sets. For a long time now, all MPE's assemblers
include the switches PREFIX and POSTFIX which allow the assemblers to
operate
in either mode. The code required to do this is about ten lines, and allows
the user to choose.
PREFIX
MOV EAX, 0 [ESP]

POSTFIX
EAX, 0 [ESP] MOV

The impact of whether or not to use prefix notation has more to do with
whether
to reduce the cost of writing the assembler, or of reducing the user's
costs.
Most users prefer the prefix notation because it makes conversion of
existing
code or fragments from data sheets much easier. It is for this reason that
MPE
tries to make the Forth assembler syntax very close to that of the
manufacturer's assembler.

In general, non-guru users prefer the PREFIX notation, but POSTFIX
assemblers
take a little less effort to write.
--

MicroProcessor Engineering - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 1703 631441, fax: +44 1703 339691
web: http://www.*-*-*.com/



Mon, 21 Feb 2000 03:00:00 GMT  
 Forth-ish assemblers

Quote:

> I've got a bit of a strange penchant for writing standalone assemblers
> with a Forth-like philosophy.  I've written two such 6502 cross-assemblers
> (for the 80x86) in the past, and am toying with writing a PowerPC
> assembler.

> Anyhow, I'm just looking for folks' experiences in writing nifty little
> assemblers in Forth.  The standard RPN assembler is certainly the easiest,
> but does anyone really write serious code using that syntax?  I've done
> 'em both ways, RPN and "normal," but the latter always gets messy and
> seems to lose some of the nice advantages of Forth.  Actually, the RPN
> syntax works fine for single operand assembly languages, like 6502, but
> looks horrendously scary for a three-operand chip like the PowerPC.

> Any experiences, etc, no matter how unrelated, would be welcomed!

> --
> James Hague
> Dadgum Games
> Grab the Bumbler Bee-Luxe demo from http://www.dadgum.com

I've written quite a bit of code using HS/FORTH's RPN assembler.

In my opinion such are preferable to (and much smaller than!) "normal"
order assemblers such as F-PC's (actually the latter lets you do it
both ways). I don't see what the problem is, really--it's a matter
of what you get used to. That is, after a while,


is no less readable than


The only advantage I can think of, for a prefix assembler is
that if you are using the Forth to develop assembly code that
will sometime later be linked to other languages (with, of
course, suitable headers and footers to handle the stack
frames and other fol-di-rol ;-) you have less editing when
you use a prefix assembler.

--
Julian V. Noble



Mon, 21 Feb 2000 03:00:00 GMT  
 Forth-ish assemblers



Quote:
> Anyhow, I'm just looking for folks' experiences in writing nifty little
> assemblers in Forth.  The standard RPN assembler is certainly the easiest,
> but does anyone really write serious code using that syntax?  I've done
> 'em both ways, RPN and "normal," but the latter always gets messy and
> seems to lose some of the nice advantages of Forth.  Actually, the RPN
> syntax works fine for single operand assembly languages, like 6502, but
> looks horrendously scary for a three-operand chip like the PowerPC.

I've written a few Forth assemblers over the years (my latest ships with
Win32Forth), and it has been my experience that it is very easy to add
postfix syntax to a prefix assembler by delaying the actual assembly of
the current instruction.  For example, in the code:

CODE FOO PUSH EBX MOV EBX, # 69 NEXT, END-CODE

which puts a 69 on the stack (in Win32Forth), the PUSH EBX isn't actually
assembled until the MOV instruction is seen.  This is handled by defering
the word that actually does the work of assembly.  For details, you can
read the source code for the assembler, available with Win32Forth, or
separately via ftp from ftp://ftp.netcom.com/pub/ja/japs/486asm.zip



Mon, 21 Feb 2000 03:00:00 GMT  
 Forth-ish assemblers

Quote:

> Most users prefer the prefix notation because it makes conversion of
> existing
> code or fragments from data sheets much easier. It is for this reason that
> MPE
> tries to make the Forth assembler syntax very close to that of the
> manufacturer's assembler.

On the other hand, if you want to port your assembler code from one CPU
to the other, the ideosyncracies of each manufacturer are annoying, and
you'd better implement your own style (like the one of Forth Inc.). And
do you really want to change your assembler simply because you moved
from Windows to Linux, where the native assembler format is that of GNU
as?

Gurus prefer postfix assemblers, and they prefer a common syntax, source
first, destination second, consistent with the rest of the Forth. I
rarely use sources from data books, since I can do it better, and even
if the source is really good, I want to understand what it does; then
the syntax transfer is simple.

--
Bernd Paysan
"Late answers are wrong answers!"
http://www.informatik.tu-muenchen.de/~paysan/



Mon, 21 Feb 2000 03:00:00 GMT  
 Forth-ish assemblers

A long time ago, in a galaxy far away, I gave a talk on the technique
mentioned by Jim.  (It might have been at FORML).
Chuck Moore gave me a nice compliment on it.  However, I find that in the
form that Jim gives, it is somewhat tricky to debug.  The forward assembler
is somewhat easier to debug if each instruction is terminated with a
special word which cleans up the instruction before going on to the next one.

Bob Smith

Quote:

>it has been my experience that it is very easy to add
>postfix syntax to a prefix assembler by delaying the actual assembly of
>the current instruction.



Tue, 22 Feb 2000 03:00:00 GMT  
 Forth-ish assemblers


Quote:

>> Anyhow, I'm just looking for folks' experiences in writing nifty little
>> assemblers in Forth.  The standard RPN assembler is certainly the easiest,
>> but does anyone really write serious code using that syntax?  I've done
>> 'em both ways, RPN and "normal," but the latter always gets messy and
>> seems to lose some of the nice advantages of Forth.  Actually, the RPN
>> syntax works fine for single operand assembly languages, like 6502, but
>> looks horrendously scary for a three-operand chip like the PowerPC.

I currently use a RPN FORTH assembler to assemble ARM assembly language.
(Advanced Risc Machine, the artist formerly known as Acorn Risc Machine)
It is a 3-operand chip, with many options and addressing modes. You can
do things like Add R1 = R2 + (R3 shifted left by R4) or fetch multiple
registers, indexed by an auto-increment register. There are many
combinations. All of this is done in a FORTH assembler taking 5 blocks.
The blocks are a bit dense, I admit, but it all fits.

I am currently using it to write the core floating-point routines
for a large neural network.

Simon



Tue, 22 Feb 2000 03:00:00 GMT  
 Forth-ish assemblers


Quote:
> A long time ago, in a galaxy far away, I gave a talk on the technique
> mentioned by Jim.  (It might have been at FORML).
> Chuck Moore gave me a nice compliment on it.  However, I find that in the
> form that Jim gives, it is somewhat tricky to debug.  The forward assembler
> is somewhat easier to debug if each instruction is terminated with a
> special word which cleans up the instruction before going on to the next one.

Where to insert this special word? Jim's solution creates problems
with something like "mov ax, #123  15 c, here ,  mov cx, ax" (if the
assembler doesn't know some special instructions). AFAIK macro's
create their special problems too.

It would be simplest to write "mov ax, #123 ;  15 c, here , ; mov cx, ax ;"

Quote:
> Bob Smith

> >it has been my experience that it is very easy to add
> >postfix syntax to a prefix assembler by delaying the actual assembly of
> >the current instruction.

-marcel


Tue, 22 Feb 2000 03:00:00 GMT  
 Forth-ish assemblers

Quote:

> Anyhow, I'm just looking for folks' experiences in writing nifty little
> assemblers in Forth....

At Dorado Systems we used Forth-based assemblers for many years (maybe
still do), both for the 6502 and 6805 cpus. These were stand-alone
assembler applications (no Forth). The assemblers have convenient
structured conditionals rather that using meaningless labels and make
for very easy-to-read code (IMHO). Macros were a snap (regular colon
definitions). Also, it was easy to add tools such as automatic checksum
calculation, eprom programming and emulator downloading and debugging.

----------------------------------------------------------------------

Finnigan Corporation            
2215 Grand Avenue Parkway        Tel: (512) 251-1574
Austin, TX  78728-3812           Fax: (512) 251-1547



Tue, 22 Feb 2000 03:00:00 GMT  
 Forth-ish assemblers


Quote:

>I currently use a RPN Forth assembler to assemble ARM assembly language.

Hello Simon Read

This is Bill Muench. I am the author of eForth. I have implemented Forth on
many processors, but not yet the ARM. I would like to have a Forth for the
Newton which uses the ARM.

Will you send me a copy of your ARM assembler?

Bee



Tue, 22 Feb 2000 03:00:00 GMT  
 Forth-ish assemblers



Quote:


> > Most users prefer the prefix notation because it makes conversion of
> > existing code or fragments from data sheets much easier. It is for
> > this reason that MPE tries to make the Forth assembler syntax very
> > close to that of the manufacturer's assembler.

> On the other hand, if you want to port your assembler code from one CPU
> to the other, the ideosyncracies of each manufacturer are annoying, and
> you'd better implement your own style (like the one of Forth Inc.). And
> do you really want to change your assembler simply because you moved
> from Windows to Linux, where the native assembler format is that of GNU
> as?

1) I said the manufacturer's assembler, in this case Intel. In addition,
I'm sure that far more people use MASM than the Gnu AS (no, that wasn't
flame bait, just a commercial consideration).

2) As a vendor, it is part of our job to make systems easier to use. The
balance between designing an assembler syntax because it is easy to write,
against similarity with existing code that the user may have to adapt to
Forth, is part of the trade offs to be considered.

When bringing up new hardware, many engineers check with code fragments
taken from data books or generated by tools such as Intel's AppBuilder
range or Motorola's MCUInit system. Many users of Forth cross compilers
are electronic engineers who have written considerable amounts of code
using conventional assemblers. They appreciate a forward assembler with
a conventional syntax.

3) From a vendor's perspective, Forth gurus are not good sales targets
because they either already have the tools they need, or would rather
spend time (at far greater cost than any vendor's tool) writing their
own system.

--

MicroProcessor Engineering - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 1703 631441, fax: +44 1703 339691
web: http://www.mpeltd.demon.co.uk



Wed, 23 Feb 2000 03:00:00 GMT  
 Forth-ish assemblers

Quote:

> 1) I said the manufacturer's assembler, in this case Intel. In addition,
> I'm sure that far more people use MASM than the Gnu AS (no, that wasn't
> flame bait, just a commercial consideration).

On Linux, nobody uses MASM, since only GNU As is available. If you would
port your Forth to Linux, this is your commercial consideration.

Quote:
> 3) From a vendor's perspective, Forth gurus are not good sales targets
> because they either already have the tools they need, or would rather
> spend time (at far greater cost than any vendor's tool) writing their
> own system.

Agreed.

--
Bernd Paysan
"Late answers are wrong answers!"
http://www.informatik.tu-muenchen.de/~paysan/



Thu, 24 Feb 2000 03:00:00 GMT  
 Forth-ish assemblers

-<stuff deleted>-

Quote:

>Where to insert this special word? Jim's solution creates problems
>with something like "mov ax, #123  15 c, here ,  mov cx, ax" (if the
>assembler doesn't know some special instructions). AFAIK macro's
>create their special problems too.

>It would be simplest to write "mov ax, #123 ;  15 c, here , ; mov cx, ax ;"

-<stuff deleted>-
>-marcel

Hello, Marcel:

Yes, that code fragment above (mov ax, #123 15 c, here , mov cx, ax) would
cause problems with my assembler, but that's because my assembler co-opted
the , (comma) as an operand separator, which is consistent with normal
assembly practice on an x86.  BTW, you can't assume that "here ," will do
anything other than store the current HERE address somewhere in data space.
In particular, , (comma) may not be the correct word to assemble executable
code.

As for the ; (semicolon) used as a separator:  If you want to force assembly
of the previous instruction, my assembler provides the word A; to do that.
There are also some words in the assembler that modify the way the assmebler
works in such a way that they are unsafe to use unless you know that the
previous instruction is done assembling.



Sun, 27 Feb 2000 03:00:00 GMT  
 Forth-ish assemblers

Quote:

>BTW, you can't assume that "here ," will do
>anything other than store the current HERE address somewhere in data space.
>In particular, , (comma) may not be the correct word to assemble executable
>code.

I think it should. Eh, let me rephrase that: there should be "comma"
word in the Assembler dictionary, that gets used inside code
definitions, and that does work as Marcel wants. Same for "here", if
necessary.

        Bart.



Mon, 28 Feb 2000 03:00:00 GMT  
 Forth-ish assemblers

Quote:


>-<stuff deleted>-

>>Where to insert this special word? Jim's solution creates problems
>>with something like "mov ax, #123  15 c, here ,  mov cx, ax" (if the
>>assembler doesn't know some special instructions). AFAIK macro's
>>create their special problems too.

>>It would be simplest to write "mov ax, #123 ;  15 c, here , ; mov cx, ax ;"

>-<stuff deleted>-
>>-marcel
>Hello, Marcel:
>Yes, that code fragment above (mov ax, #123 15 c, here , mov cx, ax) would
>cause problems with my assembler, but that's because my assembler co-opted
>the , (comma) as an operand separator, which is consistent with normal
>assembly practice on an x86.  BTW, you can't assume that "here ," will do
>anything other than store the current HERE address somewhere in data space.
>In particular, , (comma) may not be the correct word to assemble executable
>code.

Hello Marcel, hello Jim,

the same problem arose to me, when I tried last time to wrote a prefix
assembler for the 68000. My suggestion for mixing code sequences and
arbitrary data is to use a special command instead of the ','.

And why not use the syntax that the normal prefix assemblers use for that
purpose. The sequence for the 8086 looks then as follows:

        mov ax, #123  
        db 15
        dw here
        mov cx, ax

You can code 'db' and 'dw' analog to the assembler opcodes and make them
deferred until the next opcode.

I too use a separate ',' to distinguish between source and destination
operands. On the 68000 there are too much possible combinations of
registers. So I do not like the 8086 way of defining the all possible
destination operands with a trailing comma.

        Thomas



Mon, 28 Feb 2000 03:00:00 GMT  
 Forth-ish assemblers


Quote:

> -<stuff deleted>-

>>Where to insert this special word? Jim's solution creates problems
>>with something like "mov ax, #123  15 c, here ,  mov cx, ax" (if the
>>assembler doesn't know some special instructions). AFAIK macro's
>>create their special problems too.

>>It would be simplest to write "mov ax, #123 ;  15 c, here , ; mov cx, ax ;"

[..]

Quote:
> Yes, that code fragment above (mov ax, #123 15 c, here , mov cx, ax) would
> cause problems with my assembler, but that's because my assembler co-opted
> the , (comma) as an operand separator, which is consistent with normal
> assembly practice on an x86.  BTW, you can't assume that "here ," will do

The choice of example was unfortunate because I'm not interested in the c, ,
and here as such, but in the fact that the instruction is not assembled when
the programmer expects it. The action is delayed to a rather "undefined" future
moment (e.g. when the next instruction is assembled). Explicit use of A; above
would remove this confusion. Take the following quite "natural" code somebody
might try:

mov ax, #123
  ?def GAME [if] include slot_machine.asm [then]
mov cx, ax

Quote:
> anything other than store the current HERE address somewhere in data space.
> In particular, , (comma) may not be the correct word to assemble executable
> code.

I could live with that.

Quote:
> As for the ; (semicolon) used as a separator:  If you want to force assembly
> of the previous instruction, my assembler provides the word A; to do that.
> There are also some words in the assembler that modify the way the assmebler
> works in such a way that they are unsafe to use unless you know that the
> previous instruction is done assembling.

I'd do  : ;; A; ;  and be done with it (mov ax, #123 ;; "looks" better than
mov ax, #123 A;).

-marcel



Mon, 28 Feb 2000 03:00:00 GMT  
 
 [ 16 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Forth-ish assemblers

2. Announce: gslab, a Forth-ish emacs<->gs interface

3. 386 Assemblers in Forth for Forth

4. 32 bit standard forth, forth assembler, unreadability

5. The return of Forth(ish) machines? (was: Re: The return of lisp(ish) machines?)

6. Jim Schneider's Forth assembler

7. Dec Alpha Forth assembler available

8. Forth Assembler in Perl

9. Forth assemblers, are they useful?

10. PPC Forth assembler?

11. Forth assembler for PIC16C55

12. SSE extensions to Forth assembler

 

 
Powered by phpBB® Forum Software