1. Forum
  2. Usenet
  3. COMP.LANG.FORTH

  • gFORTH Metal Compiler ( or attempt at building one )

    From SpainHackForth@21:1/5 to All on Wed Aug 23 11:20:20 2023
    Hello all,

    I having some issue with some code I'm using to have a go at meta compilation, I'm building a 32 bit 'Target' and when I try to write some bytes into the Target which I have alloted space for, it just won't show up.

    Here is it is interactive in gForth:

    Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
    Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
    Type `bye' to exit
    CREATE TARGET 64 ALLOT ok
    TARGET 64 ERASE ok
    ok
    \ Lets add a word to examine our target: ok
    ok
    : .## ( c) 0 <# # # #> TYPE SPACE ; ok
    : REVIEW compiled
    BASE @ >R HEX \ Show target addess space. compiled
    2 0 DO CR 32 0 DO J 32 * I + TARGET C@ .## LOOP LOOP compiled
    R> BASE ! ; ok
    ok
    ok
    REVIEW
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ok
    ok
    \ Lets add some references to the Target address ok
    ok
    : T@ ( a) TARGET + @ ; ok
    : T! ( n a) TARGET + ! ; ok
    : TC@ ( a) TARGET + C@ ; ok
    : TC! ( n a) TARGET + C! ; ok
    ok
    \ Lets add some words to work in the target space ok
    ok
    VARIABLE TP ( Target Pointer) 1 TP ! ok
    : THERE ( - a) TP @ ; ok
    ok
    2 CONSTANT TCELL ( 2 bytes per target cell) ok
    ok
    : TC, ( n) THERE TC! 1 TP +! ; ok
    : T, ( n) THERE T! TCELL TP +! ; ok
    : RENEW TARGET 32 ERASE 1 TP ! ; RENEW ok
    ok
    \ Lets work with our target by adding bytes ok
    ok
    RENEW 1 TC, 2 TC, 3 TC, REVIEW
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ok

    Any ideas on what I have missed?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gerry Jackson@21:1/5 to SpainHackForth on Wed Aug 23 21:55:44 2023
    On 23/08/2023 19:20, SpainHackForth wrote:
    Hello all,

    I having some issue with some code I'm using to have a go at meta compilation, I'm building a 32 bit 'Target' and when I try to write some bytes into the Target which I have alloted space for, it just won't show up.

    Here is it is interactive in gForth:

    Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
    Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
    Type `bye' to exit
    CREATE TARGET 64 ALLOT ok
    TARGET 64 ERASE ok
    ok
    \ Lets add a word to examine our target: ok
    ok
    : .## ( c) 0 <# # # #> TYPE SPACE ; ok
    : REVIEW compiled
    BASE @ >R HEX \ Show target addess space. compiled
    2 0 DO CR 32 0 DO J 32 * I + TARGET C@ .## LOOP LOOP compiled
    R> BASE ! ; ok
    ok
    ok
    REVIEW
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ok

    If you execute .s here you will see 0 to 63 left on the data stack.
    That is left there by:
    I + TARGET C@
    in the inner loop of REVIEW, this should be:
    I + TARGET + C@

    I think it all works then.

    Always test your test words like REVIEW in a simple way before using
    them to test the rest of your code by putting some known data in a
    simple way. erasing it and displaying 0's isn't a lot of good.

    ok
    \ Lets add some references to the Target address ok
    ok
    : T@ ( a) TARGET + @ ; ok
    : T! ( n a) TARGET + ! ; ok
    : TC@ ( a) TARGET + C@ ; ok
    : TC! ( n a) TARGET + C! ; ok
    ok
    \ Lets add some words to work in the target space ok
    ok
    VARIABLE TP ( Target Pointer) 1 TP ! ok
    : THERE ( - a) TP @ ; ok
    ok
    2 CONSTANT TCELL ( 2 bytes per target cell) ok
    ok
    : TC, ( n) THERE TC! 1 TP +! ; ok
    : T, ( n) THERE T! TCELL TP +! ; ok
    : RENEW TARGET 32 ERASE 1 TP ! ; RENEW ok
    ok
    \ Lets work with our target by adding bytes ok
    ok
    RENEW 1 TC, 2 TC, 3 TC, REVIEW
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ok

    Any ideas on what I have missed?

    --
    Gerry

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Brian Fox@21:1/5 to Gerry Jackson on Wed Aug 23 17:41:37 2023
    On Wednesday, August 23, 2023 at 4:55:48 PM UTC-4, Gerry Jackson wrote:
    On 23/08/2023 19:20, SpainHackForth wrote:
    Hello all,

    I having some issue with some code I'm using to have a go at meta compilation, I'm building a 32 bit 'Target' and when I try to write some bytes into the Target which I have alloted space for, it just won't show up.

    Here is it is interactive in gForth:

    Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc. Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
    Type `bye' to exit
    CREATE TARGET 64 ALLOT ok
    TARGET 64 ERASE ok
    ok
    \ Lets add a word to examine our target: ok
    ok
    : .## ( c) 0 <# # # #> TYPE SPACE ; ok
    : REVIEW compiled
    BASE @ >R HEX \ Show target addess space. compiled
    2 0 DO CR 32 0 DO J 32 * I + TARGET C@ .## LOOP LOOP compiled
    BASE ! ; ok
    ok
    ok
    REVIEW
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ok

    If you execute .s here you will see 0 to 63 left on the data stack.
    That is left there by:
    I + TARGET C@
    in the inner loop of REVIEW, this should be:
    I + TARGET + C@

    I think it all works then.

    Always test your test words like REVIEW in a simple way before using
    them to test the rest of your code by putting some known data in a
    simple way. erasing it and displaying 0's isn't a lot of good.

    ok
    \ Lets add some references to the Target address ok
    ok
    : T@ ( a) TARGET + @ ; ok
    : T! ( n a) TARGET + ! ; ok
    : TC@ ( a) TARGET + C@ ; ok
    : TC! ( n a) TARGET + C! ; ok
    ok
    \ Lets add some words to work in the target space ok
    ok
    VARIABLE TP ( Target Pointer) 1 TP ! ok
    : THERE ( - a) TP @ ; ok
    ok
    2 CONSTANT TCELL ( 2 bytes per target cell) ok
    ok
    : TC, ( n) THERE TC! 1 TP +! ; ok
    : T, ( n) THERE T! TCELL TP +! ; ok
    : RENEW TARGET 32 ERASE 1 TP ! ; RENEW ok
    ok
    \ Lets work with our target by adding bytes ok
    ok
    RENEW 1 TC, 2 TC, 3 TC, REVIEW
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ok

    Any ideas on what I have missed?

    --
    Gerry

    I think it is because your target uses 2 byte cells but 32bit GForth is a 4 byte cell.
    This means you need to store and fetch 2 bytes.

    32 bit GForth that I have has W! and W@ for 2 bytes words.
    So if you change your T! and T@ to use the W words it should help.

    : T@ ( a) TARGET + W@ ;
    : T! ( n a) TARGET + W! ;

    It's interesting to see that you did something very similar to my own code. Mine is simpler because I compile on a 16 bit machine to a 16 bit target.
    I have thought for a while of rebuilding my cross-compiler on GForth.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From SpainHackForth@21:1/5 to Gerry Jackson on Thu Aug 24 03:48:48 2023
    On Wednesday, August 23, 2023 at 10:55:48 PM UTC+2, Gerry Jackson wrote:


    If you execute .s here you will see 0 to 63 left on the data stack.
    That is left there by:
    I + TARGET C@
    in the inner loop of REVIEW, this should be:
    I + TARGET + C@

    I think it all works then.

    Always test your test words like REVIEW in a simple way before using
    them to test the rest of your code by putting some known data in a
    simple way. erasing it and displaying 0's isn't a lot of good.

    Gerry
    THANK YOU!!! Let me try that...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From SpainHackForth@21:1/5 to SpainHackForth on Thu Aug 24 04:07:12 2023
    On Thursday, August 24, 2023 at 12:48:51 PM UTC+2, SpainHackForth wrote:
    On Wednesday, August 23, 2023 at 10:55:48 PM UTC+2, Gerry Jackson wrote:


    If you execute .s here you will see 0 to 63 left on the data stack.
    That is left there by:
    I + TARGET C@
    in the inner loop of REVIEW, this should be:
    I + TARGET + C@

    I think it all works then.

    Always test your test words like REVIEW in a simple way before using
    them to test the rest of your code by putting some known data in a
    simple way. erasing it and displaying 0's isn't a lot of good.
    Gerry
    THANK YOU!!! Let me try that...
    Ah, I now see where I changed my code and must have just removed the + sign there Garry, THANK YOU for capturing that... I went down a deeeeeep rat whole looking from something in how I was writing TC,

    Bryan, any benefit in using W@ vs @, I'm looking at how I build some meta-compilation for 32 bit ARMv8 so I was looking it at a byte level, I have most of the code in place, just getting some inconsistencies in building my headers, then I'm exploring how
    to get some of the variable folding in place... that is a deeper rat whole at the moment...


    Thank you both... I did create a simpler version of the REVIEW word just to check if I was doing something wrong in storing:

    : REVIEW
    BASE @ >R HEX ( Show target addess space.)
    TARGET 32 0 DO ( loop 32 times )
    DUP C@ .## ( fetch byte from address, display it, then push the address back )
    1+ ( increment the address to point to the next byte )
    LOOP
    DROP ( drop the remaining address )
    R> BASE ! ( Return address space. )
    ;

    Cheers!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From SpainHackForth@21:1/5 to Brian Fox on Thu Aug 24 03:45:53 2023
    On Thursday, August 24, 2023 at 2:41:40 AM UTC+2, Brian Fox wrote:
    On Wednesday, August 23, 2023 at 4:55:48 PM UTC-4, Gerry Jackson wrote:
    On 23/08/2023 19:20, SpainHackForth wrote:
    Hello all,

    I having some issue with some code I'm using to have a go at meta compilation, I'm building a 32 bit 'Target' and when I try to write some bytes into the Target which I have alloted space for, it just won't show up.

    Here is it is interactive in gForth:

    Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc. Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license' Type `bye' to exit
    CREATE TARGET 64 ALLOT ok
    TARGET 64 ERASE ok
    ok
    \ Lets add a word to examine our target: ok
    ok
    : .## ( c) 0 <# # # #> TYPE SPACE ; ok
    : REVIEW compiled
    BASE @ >R HEX \ Show target addess space. compiled
    2 0 DO CR 32 0 DO J 32 * I + TARGET C@ .## LOOP LOOP compiled
    BASE ! ; ok
    ok
    ok
    REVIEW
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ok

    If you execute .s here you will see 0 to 63 left on the data stack.
    That is left there by:
    I + TARGET C@
    in the inner loop of REVIEW, this should be:
    I + TARGET + C@

    I think it all works then.

    Always test your test words like REVIEW in a simple way before using
    them to test the rest of your code by putting some known data in a
    simple way. erasing it and displaying 0's isn't a lot of good.

    ok
    \ Lets add some references to the Target address ok
    ok
    : T@ ( a) TARGET + @ ; ok
    : T! ( n a) TARGET + ! ; ok
    : TC@ ( a) TARGET + C@ ; ok
    : TC! ( n a) TARGET + C! ; ok
    ok
    \ Lets add some words to work in the target space ok
    ok
    VARIABLE TP ( Target Pointer) 1 TP ! ok
    : THERE ( - a) TP @ ; ok
    ok
    2 CONSTANT TCELL ( 2 bytes per target cell) ok
    ok
    : TC, ( n) THERE TC! 1 TP +! ; ok
    : T, ( n) THERE T! TCELL TP +! ; ok
    : RENEW TARGET 32 ERASE 1 TP ! ; RENEW ok
    ok
    \ Lets work with our target by adding bytes ok
    ok
    RENEW 1 TC, 2 TC, 3 TC, REVIEW
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ok

    Any ideas on what I have missed?

    --
    Gerry
    I think it is because your target uses 2 byte cells but 32bit GForth is a 4 byte cell.
    This means you need to store and fetch 2 bytes.

    32 bit GForth that I have has W! and W@ for 2 bytes words.
    So if you change your T! and T@ to use the W words it should help.

    : T@ ( a) TARGET + W@ ;
    : T! ( n a) TARGET + W! ;

    It's interesting to see that you did something very similar to my own code. Mine is simpler because I compile on a 16 bit machine to a 16 bit target.
    I have thought for a while of rebuilding my cross-compiler on GForth.
    Ah, OK let me try that!
    Thank you.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From SpainHackForth@21:1/5 to SpainHackForth on Thu Aug 24 05:27:51 2023
    On Thursday, August 24, 2023 at 1:07:14 PM UTC+2, SpainHackForth wrote:
    On Thursday, August 24, 2023 at 12:48:51 PM UTC+2, SpainHackForth wrote:
    On Wednesday, August 23, 2023 at 10:55:48 PM UTC+2, Gerry Jackson wrote:


    If you execute .s here you will see 0 to 63 left on the data stack.
    That is left there by:
    I + TARGET C@
    in the inner loop of REVIEW, this should be:
    I + TARGET + C@

    I think it all works then.

    Always test your test words like REVIEW in a simple way before using them to test the rest of your code by putting some known data in a simple way. erasing it and displaying 0's isn't a lot of good.
    Gerry
    THANK YOU!!! Let me try that...
    Ah, I now see where I changed my code and must have just removed the + sign there Garry, THANK YOU for capturing that... I went down a deeeeeep rat whole looking from something in how I was writing TC,

    Bryan, any benefit in using W@ vs @, I'm looking at how I build some meta-compilation for 32 bit ARMv8 so I was looking it at a byte level, I have most of the code in place, just getting some inconsistencies in building my headers, then I'm exploring
    how to get some of the variable folding in place... that is a deeper rat whole at the moment...


    Thank you both... I did create a simpler version of the REVIEW word just to check if I was doing something wrong in storing:

    : REVIEW
    BASE @ >R HEX ( Show target addess space.)
    TARGET 32 0 DO ( loop 32 times )
    DUP C@ .## ( fetch byte from address, display it, then push the address back )
    1+ ( increment the address to point to the next byte )
    LOOP
    DROP ( drop the remaining address )
    BASE ! ( Return address space. )
    ;

    Cheers!
    * Variable Folding should be constant folding...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Brian Fox@21:1/5 to SpainHackForth on Thu Aug 24 07:36:57 2023
    On Thursday, August 24, 2023 at 7:07:14 AM UTC-4, SpainHackForth wrote:
    On Thursday, August 24, 2023 at 12:48:51 PM UTC+2, SpainHackForth wrote:

    Bryan, any benefit in using W@ vs @, I'm looking at how I build some meta-compilation for 32 bit ARMv8 so I was looking it at a byte level, I have most of the code in place, just getting some inconsistencies in building my headers, then I'm exploring
    how to get some of the variable folding in place... that is a deeper rat whole at the moment...

    I don't know the ARMv8 instruction set details but if there are cases where the instruction fits into 16bits then
    you can use W!.
    Of course you could make your own version using shifts and OR and two C! words but W! is there to use.

    BTW Here is how I did it for a machine with fixed size instructions of 16 bits. I just replicated the way the Forth dictionary works with a T prefix on the word names.
    It keeps my human memory load manageable.

    \ target memory management
    VARIABLE TDP \ target dictionary pointer

    \ set where the Cross-assembler puts its code
    HEX
    : ORG ( addr -- ) TDP ! ;

    : NEW 2000 2000 FF FILL 1FFF H ! ; \ H is the HEAP pointer in this system.

    \ Target versions of HERE and ALLOT
    : THERE ( -- addr) TDP @ ;
    : TALLOT ( n -- ) TDP +! ;

    \ integer and byte "Target" compilers
    : T, ( n -- ) THERE ! 1 CELLS TALLOT ;
    : TC, ( c -- ) THERE C! 1 TALLOT ;

    Later in the cross-compiler I needed to deal with relocation.
    The case is:
    - the image compiled in a buffer on the machine.
    - The programmer wants the program to load and run at a different address.

    It might be more confusing, but if it helps the source code for this Machine Forth
    is here:

    https://github.com/bfox9900/MachForth/tree/main/COMPILER/src

    Search for REL>TARG to see what I did for relocation and where it was used.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From SpainHackForth@21:1/5 to Brian Fox on Thu Aug 24 08:33:26 2023
    On Thursday, August 24, 2023 at 4:37:00 PM UTC+2, Brian Fox wrote:
    On Thursday, August 24, 2023 at 7:07:14 AM UTC-4, SpainHackForth wrote:
    On Thursday, August 24, 2023 at 12:48:51 PM UTC+2, SpainHackForth wrote:

    Bryan, any benefit in using W@ vs @, I'm looking at how I build some meta-compilation for 32 bit ARMv8 so I was looking it at a byte level, I have most of the code in place, just getting some inconsistencies in building my headers, then I'm exploring
    how to get some of the variable folding in place... that is a deeper rat whole at the moment...
    I don't know the ARMv8 instruction set details but if there are cases where the instruction fits into 16bits then
    you can use W!.
    Of course you could make your own version using shifts and OR and two C! words but W! is there to use.

    BTW Here is how I did it for a machine with fixed size instructions of 16 bits.
    I just replicated the way the Forth dictionary works with a T prefix on the word names.
    It keeps my human memory load manageable.

    \ target memory management
    VARIABLE TDP \ target dictionary pointer

    \ set where the Cross-assembler puts its code
    HEX
    : ORG ( addr -- ) TDP ! ;

    : NEW 2000 2000 FF FILL 1FFF H ! ; \ H is the HEAP pointer in this system.

    \ Target versions of HERE and ALLOT
    : THERE ( -- addr) TDP @ ;
    : TALLOT ( n -- ) TDP +! ;

    \ integer and byte "Target" compilers
    : T, ( n -- ) THERE ! 1 CELLS TALLOT ;
    : TC, ( c -- ) THERE C! 1 TALLOT ;

    Later in the cross-compiler I needed to deal with relocation.
    The case is:
    - the image compiled in a buffer on the machine.
    - The programmer wants the program to load and run at a different address.

    It might be more confusing, but if it helps the source code for this Machine Forth
    is here:

    https://github.com/bfox9900/MachForth/tree/main/COMPILER/src

    Search for REL>TARG to see what I did for relocation and where it was used.
    Awesome, THANK YOU !!! I'll have a look! Ah, relocation might be an issue latter on, I believe that might pop up when I get it running.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From SpainHackForth@21:1/5 to Brian Fox on Thu Aug 24 13:48:35 2023
    On Thursday, August 24, 2023 at 4:37:00 PM UTC+2, Brian Fox wrote:
    On Thursday, August 24, 2023 at 7:07:14 AM UTC-4, SpainHackForth wrote:
    On Thursday, August 24, 2023 at 12:48:51 PM UTC+2, SpainHackForth wrote:

    Bryan, any benefit in using W@ vs @, I'm looking at how I build some meta-compilation for 32 bit ARMv8 so I was looking it at a byte level, I have most of the code in place, just getting some inconsistencies in building my headers, then I'm exploring
    how to get some of the variable folding in place... that is a deeper rat whole at the moment...
    I don't know the ARMv8 instruction set details but if there are cases where the instruction fits into 16bits then
    you can use W!.
    Of course you could make your own version using shifts and OR and two C! words but W! is there to use.

    BTW Here is how I did it for a machine with fixed size instructions of 16 bits.
    I just replicated the way the Forth dictionary works with a T prefix on the word names.
    It keeps my human memory load manageable.

    \ target memory management
    VARIABLE TDP \ target dictionary pointer

    \ set where the Cross-assembler puts its code
    HEX
    : ORG ( addr -- ) TDP ! ;

    : NEW 2000 2000 FF FILL 1FFF H ! ; \ H is the HEAP pointer in this system.

    \ Target versions of HERE and ALLOT
    : THERE ( -- addr) TDP @ ;
    : TALLOT ( n -- ) TDP +! ;

    \ integer and byte "Target" compilers
    : T, ( n -- ) THERE ! 1 CELLS TALLOT ;
    : TC, ( c -- ) THERE C! 1 TALLOT ;

    Later in the cross-compiler I needed to deal with relocation.
    The case is:
    - the image compiled in a buffer on the machine.
    - The programmer wants the program to load and run at a different address.

    It might be more confusing, but if it helps the source code for this Machine Forth
    is here:

    https://github.com/bfox9900/MachForth/tree/main/COMPILER/src

    Search for REL>TARG to see what I did for relocation and where it was used.
    Just took a peek, and that is some clean code! thank you again for sharing this! I see some resemblance in the structure, very readable and well constrained in the sections and how you build the code up. I did not look to much into the code "yet" but I
    think I saw how you build the different opcodes based on their conditional formats, or at least that is how I'm setting up the code I'm working on, they are structured differently.

    Here is the sheet I work with to see all the opcodes: https://montcs.bloomu.edu/Information/ARMv8/legv8-green-card.compressed.pdf

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Brian Fox@21:1/5 to SpainHackForth on Thu Aug 24 16:35:30 2023
    On Thursday, August 24, 2023 at 4:48:38 PM UTC-4, SpainHackForth wrote:
    On Thursday, August 24, 2023 at 4:37:00 PM UTC+2, Brian Fox wrote:
    On Thursday, August 24, 2023 at 7:07:14 AM UTC-4, SpainHackForth wrote:
    On Thursday, August 24, 2023 at 12:48:51 PM UTC+2, SpainHackForth wrote:

    Bryan, any benefit in using W@ vs @, I'm looking at how I build some meta-compilation for 32 bit ARMv8 so I was looking it at a byte level, I have most of the code in place, just getting some inconsistencies in building my headers, then I'm
    exploring how to get some of the variable folding in place... that is a deeper rat whole at the moment...
    I don't know the ARMv8 instruction set details but if there are cases where the instruction fits into 16bits then
    you can use W!.
    Of course you could make your own version using shifts and OR and two C! words but W! is there to use.

    BTW Here is how I did it for a machine with fixed size instructions of 16 bits.
    I just replicated the way the Forth dictionary works with a T prefix on the word names.
    It keeps my human memory load manageable.

    \ target memory management
    VARIABLE TDP \ target dictionary pointer

    \ set where the Cross-assembler puts its code
    HEX
    : ORG ( addr -- ) TDP ! ;

    : NEW 2000 2000 FF FILL 1FFF H ! ; \ H is the HEAP pointer in this system.

    \ Target versions of HERE and ALLOT
    : THERE ( -- addr) TDP @ ;
    : TALLOT ( n -- ) TDP +! ;

    \ integer and byte "Target" compilers
    : T, ( n -- ) THERE ! 1 CELLS TALLOT ;
    : TC, ( c -- ) THERE C! 1 TALLOT ;

    Later in the cross-compiler I needed to deal with relocation.
    The case is:
    - the image compiled in a buffer on the machine.
    - The programmer wants the program to load and run at a different address.

    It might be more confusing, but if it helps the source code for this Machine Forth
    is here:

    https://github.com/bfox9900/MachForth/tree/main/COMPILER/src

    Search for REL>TARG to see what I did for relocation and where it was used.
    Just took a peek, and that is some clean code! thank you again for sharing this! I see some resemblance in the structure, very readable and well constrained in the sections and how you build the code up. I did not look to much into the code "yet" but I
    think I saw how you build the different opcodes based on their conditional formats, or at least that is how I'm setting up the code I'm working on, they are structured differently.

    Here is the sheet I work with to see all the opcodes: https://montcs.bloomu.edu/Information/ARMv8/legv8-green-card.compressed.pdf

    I am happy it provided some insights.
    I started with the Assembler and worked up from there.
    I also must admit that I got a helping hand from some TI engineers from 40 years ago
    who wrote an assembler for this machine in Forth.
    I did a lot of mods but it gave me the bones and the 9900 simpler than ARM.

    Makes me wonder if there is an open-source Forth Assembler for ARM that you could
    modify? Or maybe you prefer complete DIY. ??

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)