6502.org

Posted: **Fri Jan 08, 2021 10:59 pm**

Dr Jefyll wrote:

It sounds to as if the problem is that the 'Chromium' cross-compiler/assembler allows only structured control flow -- IOW, it will accept IF, ELSE, ENDIF, in the source code but not BNE BEQ and so on.

I have dealt with a similar situation when using Bill Ragsdale's RPN assembler for 6502. It sometimes happen that I want to use conditionals in an unstructured way, and I accomplish this by adding snippets in the source code, snippets which cause the necessary bytes to output. For example, ...
D0 C, DESIRED_DESTINATION HERE 1+ - C,
... will cause a BNE opcode then its 8-bit offset to be assembled.

This is somewhat messy, but it lets me "break the rules" and bypass the compiler security checking which otherwise insists that IF pair with ENDIF and so on... and the code Phillip is trying to reproduce breaks the rules in the same way.

If you search on this forum for "compiler security" then you'll find there's another (arguably less messy) way, and that involves juggling items the assembler has on stack instead. Here is one post in that vein.

My Forth assembler, which also uses structured control flow, has BRAN, .
If I want to assemble a BEQ to some_address, I do it like this:

Code: Select all

some_address 0= BRAN,

or a BNE

Code: Select all

some_address 0= NOT BRAN,

Posted: **Sat Jan 09, 2021 12:28 am**

JimBoyd wrote:

That looks like source for a metacompiler's assembler.

You're right!

JimBoyd wrote:

I don't see a bias against labels

It's certainly subjective, I'm just going by his first sentence: "Even in the era of structured programming, some programmers will insist on labels in their assembler code."

JimBoyd wrote:

My Forth assembler, which also uses structured control flow, has BRAN, .

Yes, I saw that on the earlier thread, you've obviously honed this a bit, your RPN Forth assembly source code actually looks quite good, albeit not quite a simple IF, THEN, ELSE, in construction, but generally easy on the eye. If I do decide to build out the CamelForth assembler a bit more, I'll certainly come back to it.

If this was a smaller piece of assembly, then I'd probably do the conversion, but Sargon Chess is several thousand lines long and thus I think my time is better spend using the disassembler functionality to create my source code. I'm using f9dasm, which can take an 'info' file that allows you to add comments, label names, addresses etc to the disassembly, I find it really powerful.

Posted: **Sat Jan 09, 2021 1:22 am**

pjeaton wrote:

Yes, I saw that on the earlier thread, you've obviously honed this a bit, your RPN Forth assembly source code actually looks quite good, albeit not quite a simple IF, THEN, ELSE, in construction, but generally easy on the eye. If I do decide to build out the CamelForth assembler a bit more, I'll certainly come back to it.

I do have IF, THEN, and ELSE, as well as others.
This is the source for MIN and MAX from my kernel:

Code: Select all

HEX
CODE MIN  ( N1 N2 -- N3 )
   0 ,X LDA,  2 ,X CMP,
   1 ,X LDA,  3 ,X SBC,
   LABEL MIN.RESULT
   VS IF,  80 # EOR,  THEN,
   ' NIP @  0< BRAN,
   POP JMP,  END-CODE
CODE MAX  ( N1 N2 -- N3 )
   2 ,X LDA,  0 ,X CMP,
   3 ,X LDA,  1 ,X SBC,
   MIN.RESULT JMP,  END-CODE

Quote:

If this was a smaller piece of assembly, then I'd probably do the conversion, but Sargon Chess is several thousand lines long and thus I think my time is better spend using the disassembler functionality to create my source code.

I saw your decision about that. I would not want to convert that source either.
I mentioned BRAN, to suggest another tool for the assembler 'toolbox'.
As with the example above, sometimes when writing CODE words in Forth it is more efficient to be able to branch out of the middle of a control structure than to adhere to strictly structured programming.

Posted: **Sat Jan 09, 2021 7:16 am**

Yes, CamelForth uses some similar structures, though not with a BRAN.

Code: Select all

CODE 0=     \ n/u -- flag     return true if TOS=0
    0 # CMPD,   EQ IF,
        HERE EQU TOSTRUE   -1 # LDD,  NEXT
    THEN,   CLRA,   CLRB,   NEXT ;C
 
CODE 0<     \ n/u -- flag     true if TOS negative
    TSTA,   TOSTRUE BMI,   CLRA,   CLRB,   NEXT ;C
 
CODE =      \ x1 x2 -- flag   test x1=x2
    S ,++ SUBD,   TOSTRUE BEQ,   CLRA,   CLRB,   NEXT ;C

I'm not very experienced with assembly, but this type of code reuse seems quite common and is trading a bit of readability for reduced memory space. I'm not sure if rigid structuring can produce the same flow in the same space.

6502.org

Converting traditional assembly code to Forth assembly code

Re: Converting traditional assembly code to Forth assembly c

Re: Converting traditional assembly code to Forth assembly c

Re: Converting traditional assembly code to Forth assembly c

Re: Converting traditional assembly code to Forth assembly c