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 1 of 2  [1] 2  Next page →

#60523 — Portable Assembler

So what happened with the conversation of the forth written in portable 
assembler?  Were any conclusions made?

I started a thread in comp.arch.embedded during the discussion here and it 
has taken on a whole life of its own and still going strong.  I've lost 
track of where it is going because it diverged considerably from relevance 
to the issue here.  But when they were actually talking about the portable 
assembler the consensus seemed to be that a portable assembler does not 
exist and would not be useful to create.  I'm not sure that conclusion is 
relevant to the conversation here as this portable assembler would be fairly 
specific to implementing Forth although it would have many of the same 
problems with trying to describe assembly code for many processors using a 
common instruction set and coding format.

The last few posts included Hugh trying to make detailed decisions on 
register assignments in a PDP-11 like language and many digressions into 
other topics.

Is anything happening with this?

-- 

Rick C

[toc] | [next] | [standalone]

#60527

Forth *is* a portable assembler! So is C.

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

#60528

Mark Wills wrote on 6/9/2017 2:47 PM:
> Forth *is* a portable assembler! So is C.

That was the point I was trying to make in the original thread, but Cecil 
seemed to believe there was an advantage to creating a universal assembly 
language to code in.  To me that is no different from coding a few words in 
target specific assembly.  Those primitive words serve the same function as 
the universal assembly language.  So we had a difference of opinion.

The proof of the pudding will always be in the eating, so I'm wondering if 
any pudding has been worked on as yet.

-- 

Rick C

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

#60530

On 6/9/2017 2:30 PM, rickman wrote:
> Mark Wills wrote on 6/9/2017 2:47 PM:
>> Forth *is* a portable assembler! So is C.

But you and others were arguing against C being Portable so which one is it?
> 
> That was the point I was trying to make in the original thread, but 
> Cecil seemed to believe there was an advantage to creating a universal 
> assembly language to code in.  To me that is no different from coding a 
> few words in target specific assembly.  Those primitive words serve the 
> same function as the universal assembly language.  So we had a 
> difference of opinion.
> 
But in order to write those words in assembler you have to have an 
assembler first which is the point that keeps getting missed.

> The proof of the pudding will always be in the eating, so I'm wondering 
> if any pudding has been worked on as yet.
> 
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 have been using SwiftForth for it so I been becoming familiar at the 
same time. Right now it understands a lot of MSP430 mnemonics once it's 
working OK then I will start modifying it to use somewhat more generic 
mnemonics but still very similar to the MSP430 mnemonics.

I forgot how easy it is to write an assembler in Forth, the MSP430 
addressing modes pretty much covers most decent CPUs it's just the 
generated code that is different.

Having fun with my pudding.

-- 
Cecil - k5nwa

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

#60533

Cecil Bayona wrote on 6/9/2017 4:51 PM:
> On 6/9/2017 2:30 PM, rickman wrote:
>> Mark Wills wrote on 6/9/2017 2:47 PM:
>>> Forth *is* a portable assembler! So is C.
>
> But you and others were arguing against C being Portable so which one is it?
>>
>> That was the point I was trying to make in the original thread, but Cecil
>> seemed to believe there was an advantage to creating a universal assembly
>> language to code in.  To me that is no different from coding a few words
>> in target specific assembly.  Those primitive words serve the same
>> function as the universal assembly language.  So we had a difference of
>> opinion.
>>
> But in order to write those words in assembler you have to have an assembler
> first which is the point that keeps getting missed.

We have discussed this before.  You need an assembler, but that is not the 
same thing as needing to write one.  FIG distributed many, many listings of 
Forth assembled on existing assemblers which are today universally available 
for all embedded processors possibly other than the Transputer, but likely 
even that one.


>> The proof of the pudding will always be in the eating, so I'm wondering if
>> any pudding has been worked on as yet.
>>
> 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 have been using SwiftForth for it so I been becoming familiar at the same
> time. Right now it understands a lot of MSP430 mnemonics once it's working
> OK then I will start modifying it to use somewhat more generic mnemonics but
> still very similar to the MSP430 mnemonics.
>
> I forgot how easy it is to write an assembler in Forth, the MSP430
> addressing modes pretty much covers most decent CPUs it's just the generated
> code that is different.
>
> Having fun with my pudding.

Thanks for the update.  Keep us informed.  I'd like to see good things happen.

-- 

Rick C

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

#60534

But Cecil has rediscovered the truth about assemblers in Forth.
They are not too difficult especially if you do not  try to get fancy.

You can be generating working code in a day.

Then using Forth as a macro generator you can create complex 
macros if needed to make that assembler more Forth like.

It's very much like a portable assembler when done that way.

B

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

#60539

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.

Brad Rodriguez has some nice articles on building an assembler (Build 
Your Own Assembler) in Forth including some hints on making it an Infix 
assembler.

To me a great deal of the fun in all of this is doing research on the 
subject, I really enjoy that part.

> You can be generating working code in a day.

Actually a couple of hours to generate some of the basic words to start 
generating object code. Forth is really good for this task. Also of 
great help is the Forth philosophy of keeping things simple so a very 
simple RPN assembler that gets the job done is only a couple of pages of 
code.

> 
> Then using Forth as a macro generator you can create complex
> macros if needed to make that assembler more Forth like.
> 
> It's very much like a portable assembler when done that way.
> 
> B
> 


-- 
Cecil - k5nwa

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

#60543

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
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#60564

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?

-- 
Cecil - k5nwa

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

#60611

On Saturday, 10 June 2017 16:31:20 UTC+1, Cecil - k5nwa  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?
> 
> -- 
> Cecil - k5nwa

Infix assembler is simple if you have EVALUATE.

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

#60613

Mark Wills wrote on 6/11/2017 12:07 PM:
> On Saturday, 10 June 2017 16:31:20 UTC+1, Cecil - k5nwa  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?
>>
>> --
>> Cecil - k5nwa
>
> Infix assembler is simple if you have EVALUATE.

Just for clarification, using EVALUATE for infix parsing would consist of 
the opcode being a word that calls EVALUATE to process the operands on that 
line, then executing the same code the opcode would consist of if it were 
postfix?

-- 

Rick C

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

#60614

On 6/11/2017 11:07 AM, Mark Wills wrote:
> On Saturday, 10 June 2017 16:31:20 UTC+1, Cecil - k5nwa  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?
>>
>> -- 
>> Cecil - k5nwa
> 
> Infix assembler is simple if you have EVALUATE.
> 

SwiftForth has is but I still would like to see documentation or at 
least the source to get an idea of how it's implemented.

Right now BUILDS DOES is used to create a class of instructions. Those 
classes have instructions defined that have zero one, or two operands, 
they in turn call words to use the  operands and modify the op-codes as 
needed.

I assume that once the op-code is detected you use EVALUATE to look at 
the rest of the line and pick out the operands, is this correct? If so a 
limit would be one assembler instruction per line which is not much of a 
limit.

-- 
Cecil - k5nwa

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

#60651

On Sunday, 11 June 2017 17:40:56 UTC+1, Cecil - k5nwa  wrote:
> On 6/11/2017 11:07 AM, Mark Wills wrote:
> > On Saturday, 10 June 2017 16:31:20 UTC+1, Cecil - k5nwa  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?
> >>
> >> -- 
> >> Cecil - k5nwa
> > 
> > Infix assembler is simple if you have EVALUATE.
> > 
> 
> SwiftForth has is but I still would like to see documentation or at 
> least the source to get an idea of how it's implemented.
> 
> Right now BUILDS DOES is used to create a class of instructions. Those 
> classes have instructions defined that have zero one, or two operands, 
> they in turn call words to use the  operands and modify the op-codes as 
> needed.
> 
> I assume that once the op-code is detected you use EVALUATE to look at 
> the rest of the line and pick out the operands, is this correct? If so a 
> limit would be one assembler instruction per line which is not much of a 
> limit.
> 
> -- 
> Cecil - k5nwa

Very briefly, using MOV (move) as an example:

In "regular" TMS9900 assembly language, MOV works like this:

MOV source_register,destination_register

(there are variant memory addressing schemes but I'll ignore them for now)

So, for example: MOV R1,R2

The first thing to do is to drop the use of the comma to separate the
operands. This is Forth. We don't need them, the comma is really only
there for the benefit of the parser, not the human. The comma is noise,
so we can drop it. So now we have:

MOV R1 R2

Looks like Forth already.

1 CONSTANT R1
2 CONSTANT R2

: operands ( count - n|n... )
  0 ?do evaluate loop ;

: MOV ( tib:"source destination" -- )
  \ move source reg to destination reg
  2 operands \ -- src dst
  9 lshift   \ shift dst into correct bit position
  or         \ combine src and dst operands
  $c000 or   \ combine MOV opcode
  ,          \ compile to memory
; immediate

Now I can do:

MOV R1 R2

and it compiles the correct op-code.

Of course, it gets more complex when:
* you want to add error detection
* when you want to support the various addressing modes of an instruction

When it comes to things like supporting the various addressing modes,
I like to let the dictionary do the deciding as much as possible.

For example, the 9900 has and post increment addressing mode

R1+ - R1, with post increment
*R1+ - contents of R1 with post increment.

I would use constants for these, with unused bits as flags:

1 constant R1
2 constant R2
$81 constant R1+
$82 constant R2+
$C1 constant *R1+
$C2 constant *R2+
etc

Now, MOV can check the type of the operands (using a separate, factored
word, as it will be used many times by other instructions).

Alternatively, "operands" could look at the type of the operands, and leave
a flag in addition to the operand itself. Then MOV would consume them and
assemble the appropriate opcode.

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

#61100

It could be. But I'm going after something that allows the standard TI syntax. Eg.

MOV *R1+ @1234(R4)

I've nearly done it. Just need to get back to it. The weather has been so good that I abandoned it in favour of doing fun stuff with the kids, like splashing in swimming pools in the garden and going to steam engine and classic car rallies! Got to make the most of it while they're young. Once they get to a certain age they won't want to be seen dead on the street with their dad ;-)

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

#61115

On Wednesday, June 21, 2017 at 5:49:08 AM UTC-4, Mark Wills wrote:
> It could be. But I'm going after something that allows the standard TI syntax. Eg.
> 
> MOV *R1+ @1234(R4)
> 
> I've nearly done it. Just need to get back to it. The weather has been so good that I abandoned it in favour of doing fun stuff with the kids, like splashing in swimming pools in the garden and going to steam engine and classic car rallies! Got to make the most of it while they're young. Once they get to a certain age they won't want to be seen dead on the street with their dad ;-)

Oh very cool. A complete TI parser.

Too true about the children. I am actually moving house closer to the grandkids for the same reason!

Good on ya

B

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

#61111

On Monday, June 12, 2017 at 8:30:52 AM UTC-4, Mark Wills wrote:
> On Sunday, 11 June 2017 17:40:56 UTC+1, Cecil - k5nwa  wrote:
> > On 6/11/2017 11:07 AM, Mark Wills wrote:
> > > On Saturday, 10 June 2017 16:31:20 UTC+1, Cecil - k5nwa  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?
> > >>
> > >> -- 
> > >> Cecil - k5nwa
> > > 
> > > Infix assembler is simple if you have EVALUATE.
> > > 
> > 
> > SwiftForth has is but I still would like to see documentation or at 
> > least the source to get an idea of how it's implemented.
> > 
> > Right now BUILDS DOES is used to create a class of instructions. Those 
> > classes have instructions defined that have zero one, or two operands, 
> > they in turn call words to use the  operands and modify the op-codes as 
> > needed.
> > 
> > I assume that once the op-code is detected you use EVALUATE to look at 
> > the rest of the line and pick out the operands, is this correct? If so a 
> > limit would be one assembler instruction per line which is not much of a 
> > limit.
> > 
> > -- 
> > Cecil - k5nwa
> 
> Very briefly, using MOV (move) as an example:
> 
> In "regular" TMS9900 assembly language, MOV works like this:
> 
> MOV source_register,destination_register
> 
> (there are variant memory addressing schemes but I'll ignore them for now)
> 
> So, for example: MOV R1,R2
> 
> The first thing to do is to drop the use of the comma to separate the
> operands. This is Forth. We don't need them, the comma is really only
> there for the benefit of the parser, not the human. The comma is noise,
> so we can drop it. So now we have:
> 
> MOV R1 R2
> 
> Looks like Forth already.
> 
> 1 CONSTANT R1
> 2 CONSTANT R2
> 
> : operands ( count - n|n... )
>   0 ?do evaluate loop ;
> 
> : MOV ( tib:"source destination" -- )
>   \ move source reg to destination reg
>   2 operands \ -- src dst
>   9 lshift   \ shift dst into correct bit position
>   or         \ combine src and dst operands
>   $c000 or   \ combine MOV opcode
>   ,          \ compile to memory
> ; immediate
> 
> Now I can do:
> 
> MOV R1 R2
> 
> and it compiles the correct op-code.
> 
> Of course, it gets more complex when:
> * you want to add error detection
> * when you want to support the various addressing modes of an instruction
> 
> When it comes to things like supporting the various addressing modes,
> I like to let the dictionary do the deciding as much as possible.
> 
> For example, the 9900 has and post increment addressing mode
> 
> R1+ - R1, with post increment
> *R1+ - contents of R1 with post increment.
> 
> I would use constants for these, with unused bits as flags:
> 
> 1 constant R1
> 2 constant R2
> $81 constant R1+
> $82 constant R2+
> $C1 constant *R1+
> $C2 constant *R2+
> etc
> 
> Now, MOV can check the type of the operands (using a separate, factored
> word, as it will be used many times by other instructions).
> 
> Alternatively, "operands" could look at the type of the operands, and leave
> a flag in addition to the operand itself. Then MOV would consume them and
> assemble the appropriate opcode.

Mark I may be over simplifying but I just tried a simple example in my cross-compiler/cross-assembler and it seems to work.

Given my postfix assembler:   ( ARG1 ARG2 -- ) MOV,

I just made this:

: MOV   1 PARSE EVALUATE MOV, ; 

And with that the code   R5 R7 MOV,  
created the same code as MOV R5 R7

Is it be that simple?

B

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

#60820

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.

>
>--
>Cecil - k5nwa

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#60827

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

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

#60833

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

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

#60838

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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web