Jump to content
IGNORED

Clarification of GPL MOVE code


Gazoo

Recommended Posts

GPLMOVE.txt

 

Attached is the GPLMOVE examples file. I've always used it to move stored code in Grom to execute in CPU memory as per the example near the end of the file and it has worked flawlessly. However, there are some examples that seem to contradict the format. The format is listed as MOVE #bytes,source,destination. The first example, after the first 2 short paragraphs, shows the format MOVE #bytes,destination,source. I am looking to use the GPL Move code to move data from non-indexed cpu memory to non-indexed cpu memory and want to make sure I use the correct format before typing all this code in blindly only to find it doesn't work. Can someone provide any insight as to the exact nature of the GPL Move code to move data from non-indexed cpu memory to non-indexed cpu memory?

 

Thanks,

 

Gazoo

 

 

EDIT:

 

Assembling the code MOVE >1234,@>A000,@>2000 into a compiled image will give 1 of 2 results.

 

1. >3512, >348F, >9D00, >8F1D,>00

 

or

 

2. >3512, >348F, >1D00, >8F9D,>00

 

I just need to know which. And does it really move FROM >A000 TO >2000? or FROM >2000 TO >A000?

 

Edited by Gazoo
Link to comment
Share on other sites

The GPL Programmer's Guide and Thierry's site both say your format of—MOVE #bytes,source,destination—for the GPL Assembler code is correct. However, the machine code does it the other way round. I think I read somewhere a rationalization of that scheme, but can't remember where. The example you mention is not GPL Assembler, it is an explanation of the GROM machine code generated. The third MOVE statement (your example) should assemble to (1.) and it would move from >A000 to >2000—or, following the flow of the machine code, to >2000 from >A000, which are, of course, the same thing.

 

That's how I read it. I haven't actually assembled any GPL ALC, however. Someone whose actually assembled GPL ALC, like Rich, will likely weigh in soon.

 

...lee

Link to comment
Share on other sites

The GPL Programmer's Guide and Thierry's site both say your format of—MOVE #bytes,source,destination—for the GPL Assembler code is correct. However, the machine code does it the other way round. I think I read somewhere a rationalization of that scheme, but can't remember where. The example you mention is not GPL Assembler, it is an explanation of the GROM machine code generated. The third MOVE statement (your example) should assemble to (1.) and it would move from >A000 to >2000—or, following the flow of the machine code, to >2000 from >A000, which are, of course, the same thing.

 

That's how I read it. I haven't actually assembled any GPL ALC, however. Someone whose actually assembled GPL ALC, like Rich, will likely weigh in soon.

 

...lee

 

Well, what I'm interested in is the Grom machine code generated, because that's what I'm entering into the memory editor. :)

 

I think I see where i was misreading the file, got it now. Thanks.

 

Gazoo

Edited by Gazoo
Link to comment
Share on other sites

 

Well, what I'm interested in is the Grom machine code generated, because that's what I'm entering into the memory editor. :)

 

The confusing part is that some of the moves appear to compile into code which has the source first, such as from Grom to CPU (line <0016>). Other moves appear to compile into code which has the destination first, such as from CPU to CPU (line <0011>).

 

Gazoo

 

The GPL machine code always has the destination first. The example you cite is no different. Here's my stab at breaking it down per the method in GPLMOVE.TXT:

===Listing Fragment==================================

<0016> 6030 31,12,34        MOVE >1234,G@>C000,@>2000
       6033 8F,9D,00
       6036 C0,00

===Breakdown=========================================

MOVE >1234,G@>C000,@>2000

>31      ...MOVE (>31 = move immediate count bytes from GROM to CPU RAM or VRAM)
>1234    ...>1234 bytes
>8F      ...to CPU RAM (non-indexed)
>9D00    ...at >2000 (>9D00 + >8300 = >2000)
         ...from GROM/GRAM (by virtue of MOVE opcode)
>C000    ...at >C000

...lee

Link to comment
Share on other sites

  • 2 months later...

I totally missed this thread when posted. Found it when I typed in search for GPL RND

 

MOVE in GPL from GPL Assember is this sample for the PI command in XB.

***********************************************************
*                     NUD FOR PI
***********************************************************
NPI    MOVE 8,G@CONPI,@FAC    Load constant PI
       XML  CONT
CONPI  BYTE >40,3,14,15,92,65,35,90
* 3.1415992653590E+00
***********************************************************

In GPL Assember by Ryte Data the format is MOVE #BYTES,FROM,TO

The GPL dis-assembly is always backwards from that.

Link to comment
Share on other sites

Just weighing in here but not really qualified... If my hazy memory serves me correctly, I think some of the confusion may have arisen from the RAG GPL Assembler. IIRC, it was developed completely independantly of TI. They (RAG) changed (or rather invented, since they had nothing else to go on) the formats of a couple of GPL commands. Pretty distant hazy memory from circa 1989, so I could be wrong!!

Link to comment
Share on other sites

Just weighing in here but not really qualified... If my hazy memory serves me correctly, I think some of the confusion may have arisen from the RAG GPL Assembler. IIRC, it was developed completely independantly of TI. They (RAG) changed (or rather invented, since they had nothing else to go on) the formats of a couple of GPL commands. Pretty distant hazy memory from circa 1989, so I could be wrong!!

Yea I used to us the RAG GPL Assembler and RAG GPL Linker, but found most of the extra features superfluous.

 

The other issue was the lack of examples left much unexplained and a mystery on how to use these features.

 

I do think the RAG SAMS Assembler and RAG C SAMS support a better package.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...