<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>clarity of dual dptr code</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/42103/clarity-of-dual-dptr-code</link><description> to make an assembly routine clearer to read, I want to indicate which of the 2 dptrs are used in each instance. One is fetch, another is store. 
 
So, to achieve that, I insert the following: 
 
 fptr equ dptr
sptr equ dptr 
 
And these lines error out</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: clarity of dual dptr code</title><link>https://community.arm.com/thread/122035?ContentTypeID=1</link><pubDate>Fri, 11 Jul 2003 12:46:59 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:19eadc30-4154-4130-8fd7-da1f7be79866</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;I wonder why you would call a search &lt;i&gt;within a subroutine&lt;/i&gt; a &lt;b&gt;global&lt;/b&gt; one.  To me, the latter would mean a project-wide search over all source files.&lt;br /&gt;
&lt;br /&gt;
&lt;i&gt;With a dual dptr, I have a 2000 line module in assembler where the only change of the dptr is flipping AUXR1.&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
You should consider yourself a lucky person, then.  More often than not, I have to juggle around with about 4 pointers...&lt;br /&gt;
&lt;br /&gt;
Even so, I really don&amp;#39;t see what you&amp;#39;re trying to achieve that a 4-macro (or maybe two-macros-with-parameters) solutions can&amp;#39;t handle elegantly.  A macro that actually checks/sets AUXR is certainly better than your proposal, which only documents which of the two DPTRs a given instruction is &lt;b&gt;meant&lt;/b&gt; to use, but doesn&amp;#39;t actually ensure that that&amp;#39;s the one it &lt;b&gt;does&lt;/b&gt; use.  I.e. your sptr/fptr idea may well make things worse instead of better by spreading a false impression.&lt;br /&gt;
&lt;br /&gt;
If you want more mnemonic meanings, you could always call them R_FPTR and W_FPTR and so on, too.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: clarity of dual dptr code</title><link>https://community.arm.com/thread/110412?ContentTypeID=1</link><pubDate>Fri, 11 Jul 2003 11:59:50 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:4e1d1187-53bd-4028-b9d4-bc584fd4f954</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;i&gt;Would you insist on being able to do a global search for all references to r7 or the accu, too, then?&lt;/i&gt;&lt;br /&gt;
yes, within a subroutine a list of r7 uses very often pinpoint the troublespot.&lt;br /&gt;
&lt;br /&gt;
&lt;i&gt;Values in DPTR don&amp;#39;t usually survive any long time before the same DPTR is needed for something else. Global searches thus won&amp;#39;t be very useful,&lt;/i&gt;&lt;br /&gt;
With a dual dptr, I have a 2000 line module in assembler where the only change of the dptr is flipping AUXR1.&lt;br /&gt;
&lt;i&gt;rigid comment convention that has every routine document all assumptions about main scratch register contents it makes, including any DPTRs it uses.&lt;/i&gt;&lt;br /&gt;
That&amp;#39;s plain ol&amp;#39; standard.  The problem is not between routines, it is within a routine.&lt;br /&gt;
&lt;br /&gt;
Erik&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: clarity of dual dptr code</title><link>https://community.arm.com/thread/110411?ContentTypeID=1</link><pubDate>Fri, 11 Jul 2003 11:19:37 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:10506cdf-0805-4bae-ae4e-620d30f2ef81</guid><dc:creator>Dan Henry</dc:creator><description>&lt;p&gt;&lt;i&gt;&amp;quot;Also the current A51 release handles C Macro definitions.&amp;quot;&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
Excellent!  That does what the OP asked for.  That&amp;#39;ll also take one source translation step out of my builds.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: clarity of dual dptr code</title><link>https://community.arm.com/thread/95610?ContentTypeID=1</link><pubDate>Fri, 11 Jul 2003 10:58:53 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:9cfefaf4-6a0f-4bd1-890a-4cd56b2eb941</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;i&gt;Using 4 macros will not give the ability to do a global search on the use of one of the dptrs.&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
You were talking about a different type of &amp;quot;clarity&amp;quot; than I was, then.&lt;br /&gt;
&lt;br /&gt;
Anyway, I don&amp;#39;t think I see the relevance.  Would you insist on being able to do a global search for all references to r7 or the accu, too, then?&lt;br /&gt;
&lt;br /&gt;
Values in DPTR don&amp;#39;t usually survive any long time before the same DPTR is needed for something else.  Global searches thus won&amp;#39;t be very useful, IMHO.  Search for the (hopefully) named constants you load into those DPTRs, and adhere to a rigid comment convention that has every routine document all assumptions about main scratch register contents it makes, including any DPTRs it uses.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: clarity of dual dptr code</title><link>https://community.arm.com/thread/71623?ContentTypeID=1</link><pubDate>Fri, 11 Jul 2003 10:51:03 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:9ef7a0b2-b2f5-43e7-bbcd-9844962a02b9</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;i&gt;If you want to improve on this, I think what you really need would be a set of *four* macros:&lt;/i&gt;&lt;br /&gt;
I specifically stated that that was not what I were looking for.  Using 4 macros will not give the ability to do a global search on the use of one of the dptrs.&lt;br /&gt;
&lt;br /&gt;
Erik&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: clarity of dual dptr code</title><link>https://community.arm.com/thread/40522?ContentTypeID=1</link><pubDate>Fri, 11 Jul 2003 09:44:07 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:25ec3919-006c-4be3-bed6-c0a4c9417a4d</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;If you want to improve on this, I think what you really need would be a set of *four* macros:&lt;br /&gt;
&lt;br /&gt;
&lt;pre&gt;	RDP0
	WDP0
	RDP1
	WDP1&lt;/pre&gt;
&lt;br /&gt;
where each of these either &amp;quot;R&amp;quot;eads or &amp;quot;W&amp;quot;rites DPTR #0 or #1, respectively, and a fifth one&lt;br /&gt;
&lt;br /&gt;
&lt;pre&gt;	TO_DPTR a&lt;/pre&gt;
&lt;br /&gt;
that switches over to use of DPTR #0 or #1 depending on the argument passed.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The tricky bit is to teach these macros which DPTR is the currently selected one, so they can generate&lt;br /&gt;
&lt;br /&gt;
&lt;pre&gt;	inc DPS&lt;/pre&gt;
or&lt;pre&gt;	dec DPS&lt;/pre&gt;
&lt;br /&gt;
(&lt;i&gt;or what ever your architecture uses to select one DPTR&lt;/i&gt;) if and only if they&amp;#39;re needed.  You&amp;#39;ld need a status variable to control this, and make sure you have a TO_DPTR after every entry point callable from the outside.&lt;br /&gt;
&lt;br /&gt;
In my experience, this is typically not worth the effort --- just write a comment explaining which DPTR you&amp;#39;re actually referring to in a given instruction, and religiously use the distinction between inc DPS and dec DPS to indicate which direction a DPS change is meant to take.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: clarity of dual dptr code</title><link>https://community.arm.com/thread/95603?ContentTypeID=1</link><pubDate>Fri, 11 Jul 2003 00:29:59 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:de32b981-8c56-4ed2-b9fb-33e805f9e859</guid><dc:creator>Keil  Support Intl.</dc:creator><description>&lt;p&gt;Also the current A51 release handles C Macro definitions.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: clarity of dual dptr code</title><link>https://community.arm.com/thread/71624?ContentTypeID=1</link><pubDate>Thu, 10 Jul 2003 15:30:50 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c64f999a-4450-41c6-9500-eb215d6db237</guid><dc:creator>Dan Henry</dc:creator><description>&lt;p&gt;&lt;i&gt;&amp;quot;The AX51 asssembler has a &amp;quot;LIT&amp;quot; directive that sounds like what you might want: literal text substitution of short strings rather than blocks of code, more like the C #define macro.&amp;quot;&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
Doesn&amp;#39;t AX51 handle C-like #define macros?  I seem to recall reading about that facility in the manual.&lt;br /&gt;
&lt;br /&gt;
Anyway, if it doesn&amp;#39;t or if like me, you use A51 (w/o the &amp;#39;X&amp;#39;), there are a number of &amp;quot;standalone&amp;quot; preprocessors that would do the trick.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: clarity of dual dptr code</title><link>https://community.arm.com/thread/40525?ContentTypeID=1</link><pubDate>Thu, 10 Jul 2003 15:00:19 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c9b15ecd-25ec-4974-961d-800fd8461031</guid><dc:creator>Drew Davis</dc:creator><description>&lt;p&gt;&amp;quot;inc dptr&amp;quot; is a unique instruction with its own opcode.  EQU lets you set values for an address, which winds up turning into an &amp;quot;inc &amp;lt;addr&amp;gt;&amp;quot; instruction.  I expect the assembler is unhappy because the equates don&amp;#39;t resolve to an actual address.&lt;br /&gt;
&lt;br /&gt;
You can equate symbols to A and R0-R7, but not DPTR for some reason.  No doubt DPTR&amp;#39;s 16-bit width plays into the rationale.&lt;br /&gt;
&lt;br /&gt;
The AX51 asssembler has a &amp;quot;LIT&amp;quot; directive that sounds like what you might want: literal text substitution of short strings rather than blocks of code, more like the C #define macro.&lt;br /&gt;
&lt;br /&gt;
fptr   LIT   &amp;#39;dptr&amp;#39;&lt;br /&gt;
sptr   LIT   &amp;#39;dptr&amp;#39;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>