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

Groups > comp.lang.forth > #60838

Re: Portable Assembler

Show all headers | View raw

On 6/16/2017 17:24, Cecil Bayona wrote:
> 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.

END-CODE does that.

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

I did experiment with hooking REFILL and doing the evaluation & 
generation on end of line. Horrible. The amount of flexibility you lose 
is huge.

What I do like with deferred generation is the ability to mix in Forth;

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

That compiles fine; Forth code (the DUP) and the correct scale for the 
size of a cell (the *CELL-SCALE) works just fine.

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