+Lee Stewart Posted September 29, 2015 Share Posted September 29, 2015 (edited) One thing to add to post #71 regarding WinAsm99 (also called Asm994a) is that, for labels on lines by themselves followed by a labeled instruction/directive, EVEN is always generated by the assembler, regardless of the byte or word nature of the next directive/instruction. ...lee Edited September 29, 2015 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
Asmusr Posted September 29, 2015 Share Posted September 29, 2015 It is my impression that WinAsm99 has been the de facto standard for several years, perhaps more important to ensure backwards compatibility with that than the old E/A? But there's no reason it shouldn't be possible to support both using a switch. WinAsm99 has quite a few bugs, but the ability to place several labels after each other and trust that they all point to the same address is not one of them, but a nice feature. Disregarding the even/odd issue, if you place two labels after each other before a correctly aligned word, will xas99 and E/A also assign different addresses to those? Quote Link to comment Share on other sites More sharing options...
ralphb Posted September 29, 2015 Author Share Posted September 29, 2015 One thing to add to post #71 regarding WinAsm99 (also called Asm994a) is that, for labels on lines by themselves, EVEN is always generated by the assembler, regardless of the byte or word nature of the next directive/instruction. I'm not sure if I understand you correctly, but wouldn't this imply that . BYTE 1 L BYTE 2 . and . BYTE 1 L BYTE 2 . produce different results?! Now that would be unexpected ... Quote Link to comment Share on other sites More sharing options...
Asmusr Posted September 29, 2015 Share Posted September 29, 2015 It is my impression that WinAsm99 has been the de facto standard for several years, perhaps more important to ensure backwards compatibility with that than the old E/A? But there's no reason it shouldn't be possible to support both using a switch. WinAsm99 has quite a few bugs, but the ability to place several labels after each other and trust that they all point to the same address is not one of them, but a nice feature. Disregarding the even/odd issue, if you place two labels after each other before a correctly aligned word, will xas99 and E/A also assign different addresses to those? I can answer my own question because I finally got Bouncy up and running with xas99 and it turns out it was an issue of misunderstanding how the conditional assembly works rather than a problem with the labels. The odd/even thing was a red herring for this project. Two labels in front of a word do get the same values under normal circumstances. Quote Link to comment Share on other sites More sharing options...
ralphb Posted September 29, 2015 Author Share Posted September 29, 2015 Disregarding the even/odd issue, if you place two labels after each other before a correctly aligned word, will xas99 and E/A also assign different addresses to those? Yes, then those will have the same value -- automatic word-alignment is the only case I can think of right now where this would differ. Also note this case here: . MSG TEXT 'HELLO' MSGE CLR R0 LI R1,MSG LI R2,MSGE-MSG BLWP @VMBW . This seems quite reasonable code to me, but it requires that MSGE truly points to the end of the string, and not some potential padding character. . It is my impression that WinAsm99 has been the de facto standard for several years, perhaps more important to ensure backwards compatibility with that than the old E/A? . That's a reasonable (and strong) argument in favor of Winasm, even though I personally think that the design is worse -- see my previous examples about EQU and strings). But just how common is this case anyway? How many explicit EVEN statements would you have to insert for your games? Quote Link to comment Share on other sites More sharing options...
ralphb Posted September 29, 2015 Author Share Posted September 29, 2015 I can answer my own question because I finally got Bouncy up and running with xas99 and it turns out it was an issue of misunderstanding how the conditional assembly works rather than a problem with the labels. The odd/even thing was a red herring for this project. Two labels in front of a word do get the same values under normal circumstances. . Oh, I wrote my previous reply in parallel to your post, so I'm glad that it worked out for you. Please note that I truly appreciate all of your feedback (including Lee and all others), since you all have much more experience in writing actual assembly programs than I do. So your input on matters of practicality really matter. Regarding the multi-label-even-odd-thing: Maybe I'll add a switch (or #pragma) if it simplifies things ... Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 29, 2015 Share Posted September 29, 2015 I'm not sure if I understand you correctly, but wouldn't this imply that . BYTE 1 L BYTE 2 . and . BYTE 1 L BYTE 2 . produce different results?! Now that would be unexpected ... I misspoke! Your two examples do, indeed, produce the same, odd-labeled code. However, if the first example also has a label in front of the second statement, the EVEN directive is auto-generated to force both labels to the same, even address: Asm994a TMS99000 Assembler - v3.010 1 0000 01 BYTE 1 2 L1 3 0001 0000 EVEN *>>> Assembler Auto-Generated <<< 4 0002 02 L2 BYTE 2 5 0003 0000 END 5 Assembly Complete - Errors: 0, Warnings: 0 ------ Symbol Listing ------ L1 REL:0002 L1 L2 REL:0002 L2 ...lee Quote Link to comment Share on other sites More sharing options...
ralphb Posted September 29, 2015 Author Share Posted September 29, 2015 (edited) I misspoke! Your two examples do, indeed, produce the same, odd-labeled code. However, if the first example also has a label in front of the second statement, the EVEN directive is auto-generated to force both labels to the same, even address: OK, I see, but that isn't better. Now . BYTE 1 L1 L2 BYTE 2 . and . BYTE 1 BYTE 2 . will produce different code ... Alright, let's see if we can bump this thread to your thread's length ... I'll be here all night ... EDIT: On second thought, Winasm probably isn't really generating an EVEN, right? It merely adjusts the label value, I assume ... But then how do you refer to an odd address?! Edited September 29, 2015 by ralphb Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 29, 2015 Share Posted September 29, 2015 OK, I see, but that isn't better. Now . BYTE 1 L1 L2 BYTE 2 . and . BYTE 1 BYTE 2 . will produce different code ... Yup. Alright, let's see if we can bump this thread to your thread's length ... I'll be here all night ... Well, that is two and a half years of rambling! EDIT: On second thought, Winasm probably isn't really generating an EVEN, right? It merely adjusts the label value, I assume ... But then how do you refer to an odd address?! I would say that it is. Look at line #3 of the listing in my last post. The only way to get WinAsm to let you keep the odd label, when the next instruction/directive demands (according to WinAsm) an even address, is to interpose a BYTE directive (or similarly byte-oriented directive). Your example of needing to point to the byte immediately following a TEXT directive is the best reason I see for your argument that WinAsm should not be messing with labels not on instruction/directive lines. ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted September 29, 2015 Share Posted September 29, 2015 I think even BES points to the even address IIRC. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted September 29, 2015 Share Posted September 29, 2015 I have now officially switched over to xas99. From now on I'm going to feast on advanced expressions and local labels . Thanks to Ralph for all the work you have put into creating these great tools. 3 Quote Link to comment Share on other sites More sharing options...
Tursi Posted September 30, 2015 Share Posted September 30, 2015 I'm a bit late to the party, but the automatic alignment in Win99Asm actually caused me grief and was a feature I did not like. So glad to see it go. When it matters you're supposed to use EVEN yourself. I'll have to try this new toolchain when I get a chance! 2 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted September 30, 2015 Share Posted September 30, 2015 (edited) Me too (have to try it out) - fifth banana. So even if a label should compile to where you set it (byte oriented), assembler program instructions (or is it a subset) should only compile to word boundaries or at least give a warning ? Edited September 30, 2015 by sometimes99er 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 30, 2015 Share Posted September 30, 2015 Me too (have to try it out). So even if a label should compile to where you set it (byte oriented), assembler program instructions (or is it a subset) should only compile to word boundaries or at least give a warning ? The following paragraph first appears in the E/A Manual, SECTION 6: “ARITHMETIC INSTRUCTIONS”, p. 79, and is included in every section describing CPU instructions: Use of the label field is optional. When it is used, the label is assigned the address of the instruction. The Assembler advances to the location of a word boundary (even address) before assembling a machine instruction. Also, here is what appears in §14.1.6 “Word Boundary--EVEN”, p. 214: Application notes: The EVEN directive ensures that the program is at an even word boundary when a statement that consists of only a label is preceded by a TEXT or BYTE directive and is followed by a DATA directive or a machine instruction. In this case, the label does not have the same value as a label in the following instruction unless the TEXT or BYTE directive left the Location Counter on an even (word) location. Using an EVEN directive before or after a machine instruction or a DATA directive is redundant since the Assembler automatically advances the Location Counter to an even address when it processes a machine instruction or a DATA directive. I don't believe the TI Assembler issues any warning when it moves the LC. And, as @ralphb mentioned somewhere above, the E/A Manual is flat out wrong in its description of the EVEN directive where it says that a label in the label field of the EVEN directive is assigned the value of the LC before the LC is advanced to a word boundary. The TI Assembler actually advances the LC before assigning its value to the label. ...lee Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted September 30, 2015 Share Posted September 30, 2015 Well, I went from the line-by-line assembler back in the eighties to tiasm (v9t9) in 2004 and that one surely allowed instructions to be output on uneven addresses, and quite a few emulators didn't choke on that. A few years later I saw some of my demos running into problems on the real deal. Quote Link to comment Share on other sites More sharing options...
ralphb Posted September 30, 2015 Author Share Posted September 30, 2015 I have now officially switched over to xas99. I'll have to try this new toolchain when I get a chance! Thanks! Knowing that the Top Bananas actually use xas99 makes me just a little bit scared. (Well, "top banana" was one of first English colloquialisms we learned in middle school ... I wonder if a single native speaker had ever used it. ) 2 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 30, 2015 Share Posted September 30, 2015 Thanks! Knowing that the Top Bananas actually use xas99 makes me just a little bit scared. (Well, "top banana" was one of first English colloquialisms we learned in middle school ... I wonder if a single native speaker had ever used it. ) Though the colloquialism seems to have originated in 1950s British burlesque, it’s use has certainly been widespread on this side of the pond. I have used it quite a bit over my 72 years on this planet! Also, “second banana”. Re your xas99, @ralphb, this second banana will definitely be giving it a spin—perhaps, for my next build of the fbForth 2.0 cartridge. ...lee 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 30, 2015 Share Posted September 30, 2015 @ralphb, what is the maximum number of labels xas99 will permit? WinAsm99 choked when I got to about 3000 labels. ...lee Quote Link to comment Share on other sites More sharing options...
ralphb Posted September 30, 2015 Author Share Posted September 30, 2015 what is the maximum number of labels xas99 will permit? WinAsm99 choked when I got to about 3000 labels. Well, there's no particular upper bound on anything (err, although I think I capped the number of nested COPYs/macros to 100 or something like that in order to prevent accidental endless recursion). I'm not particular economical about memory; for example, I read the entire source code into memory before doing anything. This would be a no-go for any current compiler, but I figured that the output could hardly exceed a couple dozen kilobytes on the TI 99, which any PC should be able to handle. Speed is another matter, but it will take some large assembly project to really stress-test xas99 for the first time. Quote Link to comment Share on other sites More sharing options...
palmheads Posted September 30, 2015 Share Posted September 30, 2015 Thanks! Knowing that the Top Bananas actually use xas99 makes me just a little bit scared. (Well, "top banana" was one of first English colloquialisms we learned in middle school ... I wonder if a single native speaker had ever used it. ) Don't forget me! I also use it! I'm not so much a top banana though, more like the end of the banana - little bit rotten, little bit useless etc cheers Daryn 1 Quote Link to comment Share on other sites More sharing options...
ralphb Posted October 2, 2015 Author Share Posted October 2, 2015 I've added support for XORG and banked memory. It's not part of the release ZIP file yet, so just grab the updated xas99 file directly and have a look at the updated manual. The XORG directive changes the LC without affecting the placement of the code so that the segment can be copied verbatim to a different location and run: . AORG >6000 L1 DATA 0 MOV @L1,@L2 ; moves >6000 to >8380 BL @FUNC ; branches to >8382 A1 XORG >8380 L2 DATA 0 FUNC A @L2,@L1 ; adds >8380 to >6000 RT . This required some thought to shoehorn the result into the tagged object code format, and I hope I got it right. Banked memory is handled by the AORG directive, which now has an additional argument, indicating the bank. . AORG >6000,0 L1 B @L3 ; OK B @L2 ; error: different bank AORG >6000,1 L2 B @L3 ; OK B @L1 ; error: different bank AORG >A000 L3 B @L1 ; OK, needs correct bank B @L2 ; OK, needs correct bank . xas99 checks for invalid cross-bank accesses, but it cannot check whether the right bank is active when accessing a given address. The new -b generation option (for "raw binary") yields the plain binary result of the assembly without any metadata, one file per segment and bank. This is intended for putting the result into EPROMs and such. The new SAVE directive controls which memory areas to save, similar to the SFIRST/SLAST symbols of the original SAVE utility. Empty areas will be padded with >00. Example: . SAVE >A000,>A010 ; save >A000, ..., >A00F RORG >0004 DATA >1234 AORG >A008 DATA >5678 . yields a single file savesample_a000.bin with contents . 00 00 00 00 12 34 00 00 56 78 00 00 00 00 00 00 . when assembled with . xas99.py -b savesample.a99 --base ">a000" .. Thanks to Rasmus and Willsy for their suggestions about these new features! If I got it wrong just let me know on how to improve it. Cheers, Ralph (Top Potato) 4 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 17, 2015 Share Posted October 17, 2015 I'm still getting assertion error with the IDEA plugin. (36,37), text: , language = Language: Xas99: (36,37), text: , language = Language: Xas99 java.lang.AssertionError: (36,37), text: , language = Language: Xas99 at com.intellij.lang.folding.FoldingDescriptor.<init>(FoldingDescriptor.java:97) at com.intellij.lang.folding.FoldingDescriptor.<init>(FoldingDescriptor.java:78) at com.intellij.lang.folding.FoldingDescriptor.<init>(FoldingDescriptor.java:63) at com.intellij.lang.folding.FoldingDescriptor.<init>(FoldingDescriptor.java:55) at net.endlos.xdt99.xas99.Xas99FoldingBuilder.buildFoldRegions(Xas99FoldingBuilder.java:28) at com.intellij.lang.folding.LanguageFolding.buildFoldingDescriptors(LanguageFolding.java:83) at com.intellij.codeInsight.folding.impl.FoldingUpdate.a(FoldingUpdate.java:205) at com.intellij.codeInsight.folding.impl.FoldingUpdate.a(FoldingUpdate.java:118) at com.intellij.codeInsight.folding.impl.FoldingUpdate.access$000(FoldingUpdate.java:52) at com.intellij.codeInsight.folding.impl.FoldingUpdate$2.compute(FoldingUpdate.java:104) at com.intellij.codeInsight.folding.impl.FoldingUpdate$2.compute(FoldingUpdate.java:99) at com.intellij.psi.impl.PsiParameterizedCachedValue.doCompute(PsiParameterizedCachedValue.java:53) at com.intellij.util.CachedValueBase.getValueWithLock(CachedValueBase.java:199) at com.intellij.psi.impl.PsiParameterizedCachedValue.getValue(PsiParameterizedCachedValue.java:43) at com.intellij.psi.util.CachedValuesManager.getParameterizedCachedValue(CachedValuesManager.java:77) at com.intellij.codeInsight.folding.impl.FoldingUpdate.updateFoldRegions(FoldingUpdate.java:98) at com.intellij.codeInsight.folding.impl.CodeFoldingManagerImpl.a(CodeFoldingManagerImpl.java:303) at com.intellij.codeInsight.folding.impl.CodeFoldingManagerImpl.updateFoldRegionsAsync(CodeFoldingManagerImpl.java:295) at com.intellij.codeInsight.daemon.impl.CodeFoldingPass.doCollectInformation(CodeFoldingPass.java:46) at com.intellij.codeHighlighting.TextEditorHighlightingPass.collectInformation(TextEditorHighlightingPass.java:62) at com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass$1$1.run(PassExecutorService.java:380) at com.intellij.openapi.application.impl.ApplicationImpl.tryRunReadAction(ApplicationImpl.java:1154) at com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass$1.run(PassExecutorService.java:371) at com.intellij.openapi.progress.ProgressManager.executeProcessUnderProgress(ProgressManager.java:209) at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:212) at com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass.a(PassExecutorService.java:368) at com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass.run(PassExecutorService.java:344) at com.intellij.concurrency.JobLauncherImpl$VoidForkJoinTask.exec(JobLauncherImpl.java:193) at jsr166e.ForkJoinTask.doExec(ForkJoinTask.java:260) at jsr166e.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:858) at jsr166e.ForkJoinPool.scan(ForkJoinPool.java:1687) at jsr166e.ForkJoinPool.runWorker(ForkJoinPool.java:1642) at jsr166e.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:109) To reproduce this all I need to do is to create two comments with a line between, then add a space to the empty line: * a * b Now each time I click in the text I get the error. Thanks for your help, Rasmus Quote Link to comment Share on other sites More sharing options...
ralphb Posted October 20, 2015 Author Share Posted October 20, 2015 I'm still getting assertion error with the IDEA plugin. (36,37), text: , language = Language: Xas99: (36,37), text: , language = Language: Xas99 java.lang.AssertionError: (36,37), text: , language = Language: Xas99* Thanks again for the report! I can reproduce this, but only with IDEA 13, IDEA 14 is fine. BTW, the TAB key should also be broken in IDEA 13 -- can you confirm this, or did you disable the TAB action somehow as a workaround? I finally may have to release separate versions for IDEA 13 and IDEA 14, respectively. Not sure if I'll get to it before my upcoming vacation, though. You could use ; comments as another workaround. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 20, 2015 Share Posted October 20, 2015 Thanks again for the report! I can reproduce this, but only with IDEA 13, IDEA 14 is fine. BTW, the TAB key should also be broken in IDEA 13 -- can you confirm this, or did you disable the TAB action somehow as a workaround? I finally may have to release separate versions for IDEA 13 and IDEA 14, respectively. Not sure if I'll get to it before my upcoming vacation, though. You could use ; comments as another workaround. The tab key works OK, but there a few weird things, like when you enter B followed by Tab you get {}. No rush for a fix, the error is not bothering me much and I can also switch to the free version of IDEA 14. Quote Link to comment Share on other sites More sharing options...
ralphb Posted October 21, 2015 Author Share Posted October 21, 2015 Well, the space-between-comments exception seems to be a bug in IDEA 13 (or rather, an overzealous assert). Fortunately, exceptions rarely affect the editor overall. I've created a workaround for the IDEA 13 bug and attached an updated JAR specifically for IDEA 13. This one also knows about the newest additions to xas99. Updating the main release bundle might take some time, though. The tab key works OK, but there a few weird things, like when you enter B followed by Tab you get {}. That's the Live Templates from the stock IDE -- probably best to deactivate them in the settings. TAB key handling in 13 should now mirror that in 14. xdt99-idea-13.zip 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.