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

Groups > comp.lang.forth > #60833

Re: Portable Assembler

Show all headers | View raw

On 6/16/2017 9:09 AM, Alex wrote:
> 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:

>>
>> 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.
> 

That is the similar to the approach described in "Build Your Own 
Assembler" by Brad Rodriguez and I have used in the past. If a next 
instruction is not found one has to look for several special cases like 
End of File but it's not a big issue.

Currently I'm looking at implementing a version that runs EVALUATE as 
part of the macro that executes when an instructions is executed to pick 
up the arguments before finishing putting the final op-code together. 
Looking back at some notes I did try something similar in the past but 
by executing each token on the line with the instruction one at a time 
to get the operands, evaluating the whole line is a little simpler.

-- 
Cecil - k5nwa

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