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

Groups > comp.lang.forth > #60827

Re: Portable Assembler

Show all headers | View raw

On 6/16/2017 14:02, Albert van der Horst wrote:
> In article <ohh35g$ab3$1@dont-email.me>,
> Cecil Bayona  <cbayona@cbayona.com> wrote:
>> On 6/10/2017 1:36 AM, Albert van der Horst wrote:
>>> In article <ohfi44$3i9$1@dont-email.me>,
>>> Cecil Bayona  <cbayona@cbayona.com> 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.
>>>
>>> I've an infix assembler called postfix. Dat is not more work.
>>> A full pentium I assembler is 90 lines. (floating point and all).
>>>>>
>>>>
>>>>
>>>> --
>>>> Cecil - k5nwa
>>
>> Got a link to some documentation?
> 
> I got the name wrong. It is posit-fixup. The idea is to post the
> opcode, leaving holes, then later fix that up. This is an ai
> design pattern called "blackboard". (I found that out after the fact.)
>     http://home.hccnet.nl/a.w.m.van.der.horst/ciasdis.html
>        (includes a debian package for ciasdis)
>     http://home.hccnet.nl/a.w.m.van.der.horst/positfixup.html
> 
> This is a sample of the assembler chapter of the ciforth doc's:
> 
> "
>     A simple example to illustrate this problem is
>              INC [BX]
>             Are we to increment the byte or the word at BX? Intel's
>             solution is `INC BYTE POINTER BX') Contrarily here we adapt
>             the rule: if an instruction doesn't determine the operand
>             size (some do, like `LEA,' ), then a size fixup is needed (
>             `X|' or `B|' ).
>             In this assembler this looks like
>                  INC, B| ZO| [BX]
>                     This is completely unambiguous.
> 
>     These are the phases in which this assembler handles an instruction:
> 
>     * POSTIT phase: `MOV,'  assembles a two byte instruction with holes.
> 
>     * FIXUP phase: `X|'  or `B|'  fits in one of the holes left.  Other
>      fixups determine registers and addressing mode.
> 
>   * COMMA phase: First check whether the fixups have filled up all
>        holes.  Then add addresses (or offsets) and/or immediate data,
>             using e.g. `IL,'  or `L,'
> 
>     * Check whether all commaers, requested either by postit's or fixup's
>          are present.  This check is actually executed by the next postit
>               prior to assembling, or by `END-CODE' .
> 
> "
> 
> This principle allows
> - an ironclad error detection, using bitmaps
>     this includes size of immediate data mistakes, or warn that SSE2
>      instructions are not available, 16 bits instructions in 32 bit mode.
> - inform about possible continuation of a current instruction at every
>      stage of completion, interactively
> - disassembler based on the same tables
> 
> It is also instrumental to my tool to run arrayforth comfortably,
> (i.e. with the possibility of source control and seeing colors
> using vim syntax coloring.)
> Note that this required a plugin to handle Huffman-encoded names.
> (This is the effort that has been ridiculed by the late Jeff Fox.)
> 
> Leaving out error detection, the assembler becomes very compact.
> A dozen screens makes a Pentium I assembler, and makes it practical
> to have a floating point wordset as a loadable extension in ciforth.

That's an interesting technique.

I took an approach for WF32 that was partly inspired by Win32Forth, and 
partly by wanting an assembler that read more like a traditional one. In 
effect, generation of the code takes place when the next opcode is seen. So

   mov word { 40 ebx ecx *4 } 20
   ret

collects all the information needed into variables or on the stack. In 
this case, a MOV operation; an operand size modifier for 2 bytes; an 
address start indicated by the opening brace; an offset of 40; a base 
register of EBX; an index ECX scaled by *4, and a constant 20 on the 
stack. It then generates the code on the next opcode seen, in this case, 
the RET.

Delaying until the very end also allows the shortest code to be 
generated; the example above is using an 8 bit offset (40) rather than a 
full 32.

The alternative is op.x where X represents the operand size or other; 
for example MOV.I for immediate, MOV.D for 32bit, MOV.Q for 64 and so 
on. That would reduce the effort but significantly increase the 
assembler word count, and for a lot of instructions is overkill. A MOV 
to AX must be a word sized operand.

-- 
Alex

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web