JWANKERL@UTCVM.BITNET ("Josef W. Wankerl") (05/10/89)
BIG OOOOOOOPS!!! I didn't mean JML... I meant BRL. (They both have L so I guess that's what messed me up. I have it straight when I program... :-) They're both 3 byte instructions, but is there any difference in execution time? On range? Sorry for the last confusing mail. -Gonzo /**********************************************************************\ |* Joe "Gonzo" Wankerl |*| *| |* |*| The views expressed here are *| |* BitNet => JWANKERL@UTCVM |*| not necessarily yours... *| |* |*| ...but they should be. *| \**********************************************************************/
farrier@Apple.COM (Cary Farrier) (05/11/89)
In article <8905101021.aa15777@SMOKE.BRL.MIL> JWANKERL@UTCVM.BITNET ("Josef W. Wankerl") writes: >BIG OOOOOOOPS!!! > >I didn't mean JML... I meant BRL. (They both have L so I guess that's >what messed me up. I have it straight when I program... :-) > > >They're both 3 byte instructions, but is there any difference in >execution time? On range? > The advantage of a JMP is that you can use absolute [ JMP addr ], absolute indirect [ JMP (addr) ], and absolute indexed indirect [ JMP(addr,x) ]. A BRL can only use absolute [ BRL addr ]. The BRL is, however, relocatable. This is good in case you wish to move a segment of code from one memory location to another. About exection times and instruction sizes: BRL addr 4 cycles 3 bytes JMP addr 3 cycles 3 bytes JMP (addr) 5 cycles 3 bytes JMP (addr,x) 6 cycles 3 bytes Both have the same range. Cary Farrier
blochowi@cat28.CS.WISC.EDU (Jason Blochowiak) (05/11/89)
In article <8905101021.aa15777@SMOKE.BRL.MIL> JWANKERL@UTCVM.BITNET ("Josef W. Wankerl") writes: >I didn't mean JML... I meant BRL. (They both have L so I guess that's >what messed me up. I have it straight when I program... :-) > >They're both 3 byte instructions, but is there any difference in >execution time? On range? According to Leo J. Scanlon's _Apple IIGS Assembly Language Programming_, a BRL takes 3 cycles, and a JMP Absolute also takes 3 cycles. I've learned not to trust the book, but this seems reasonable. Anyways, it would seem that their range is exactly the same, it's just a matter of how one gets to the destination - by using an absolute, or by using a relative address. The BRL won't require an entry in the relocation dictionary, but the JMP will - then again, I don't think this is a real consideration while coding, unless you're REAL tight for memory. Obviously, BRL is relocatable, so you can use it in a chunk of code that will move around after being loaded (btw, there's a neat "relative JSR" that can be done with a PER and a BRL - I think it's PER #2, but I'm not sure). So, I suppose BRL has the advantage when you're within your own code, but isn't much good for calling ROM locations (which would only be useful in ProDOS 8 programs, methinks) or a fixed address in your code (which seems pretty daft, seeing as the relocator exists). > -Gonzo ------------------------------------------------------------------------------ Jason Blochowiak (blochowi@garfield.cs.wisc.edu) "Not your average iconoclast..." ------------------------------------------------------------------------------
delton@pro-carolina.cts.com (Don Elton) (05/11/89)
Network Comment: to #2452 by obsolete!JWANKERL%UTCVM.BITNET%cunyvm.cuny.edu
A JMP has 3 cycles and more addressing modes while BRL has only one addressing
mode and takes 4 cycles but BRL is relocatable without modifying the argument
while JMP isn't.
UUCP: [ sdcsvax nosc ] !crash!pro-carolina!delton
ARPA: crash!pro-carolina!delton@nosc.mil
INET: delton@pro-carolina.cts.com
Pro-Carolina: 803-776-3936 (300-2400 baud, login as 'register')
US Mail: 3207 Berkeley Forest Drive, Columbia, SC 29209-4111shawn@pnet51.cts.com (Shawn Stanley) (05/11/89)
JWANKERL@UTCVM.BITNET ("Josef W. Wankerl") writes: >BIG OOOOOOOPS!!! > >I didn't mean JML... I meant BRL. (They both have L so I guess that's >what messed me up. I have it straight when I program... :-) > > >They're both 3 byte instructions, but is there any difference in >execution time? On range? > >Sorry for the last confusing mail. They both have the same execution time, and they both have the same range (if you compare the absolute JMP to the BRL). Note that you *can't* branch outside the current 64K bank with BRL, although it does include a 16-bit offset. This is what gives it the same range as the absolute JMP. As you mentioned before, it takes up less space in the final product because it doesn't have to relocate a branch. Someone mentioned that a good assembler would change JMP to BRL during the assembly. (Actually, he said it would change JMP to JML, but we know what he meant. :-) Again, I would hope not. Optimizing assemblers aren't for me; if I enter something, I *mean* that something. And a mod from JMP to BRL, although it seems harmless, will actually cause problems if you use self-modifying code. Optimization belongs in compilers, where it's at a high enough level that you aren't necessarily spinning your wheels for days trying to find a bug when the real cause was assembler optimization. (I'm not saying optimization can't go too far in compilers; consider the optimizing-out of C for-loops that have no conditions (infinite for-loops), when all you want to do is run through a menu until the user quits.) UUCP: {uunet!rosevax, amdahl!bungia, chinet, killer}!orbit!pnet51!shawn INET: shawn@pnet51.cts.com
mattd@Apple.COM (Matt Deatherage) (05/12/89)
In article <1135@orbit.UUCP> shawn@pnet51.cts.com (Shawn Stanley) writes: >Someone mentioned that a good assembler would change JMP to BRL during the >assembly. (Actually, he said it would change JMP to JML, but we know what he >meant. :-) No, I think he actually meant what he said. The point was that any assembler worth it's salt is not so picky as to refuse to generate a long jump instruction (usually abbreviated JML) if you force long addressing on a JMP. In other words, a good assembler should generate the same code for JMP >LongOffset as it would for JML LongOffset. (Now don't confuse my use of "offset" up there with thinking I really mean "branch". I mean "jump". I'm just testing y'all.) >UUCP: {uunet!rosevax, amdahl!bungia, chinet, killer}!orbit!pnet51!shawn >INET: shawn@pnet51.cts.com ----------------------------------------------------------------------------- Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome Send PERSONAL mail ONLY (please) to: | should not be construed to imply that AppleLink PE: Matt DTS GEnie: AIIDTS | Apple Computer, Inc., or any of its CompuServe: 76703,3030 | subsidiaries, in whole or in part, Usenet: mattd@apple.com | have any opinion on any subject." UUCP: (other stuff)!ames!apple!mattd | "So there." -----------------------------------------------------------------------------
farrier@Apple.COM (Cary Farrier) (05/12/89)
In article <1135@orbit.UUCP> shawn@pnet51.cts.com (Shawn Stanley) writes: >Someone mentioned that a good assembler would change JMP to BRL during the >assembly. (Actually, he said it would change JMP to JML, but we know what he >meant. :-) Again, I would hope not. Optimizing assemblers aren't for me; if >I enter something, I *mean* that something. And a mod from JMP to BRL, >although it seems harmless, will actually cause problems if you use >self-modifying code. WRONG! Like you, I *mean* what I say. I said a good assembler will change a JSR to a JSL *if* the destination address requires it! Please don't put words into other peoples mouths just to make your point. Cary Farrier
farrier@Apple.COM (Cary Farrier) (05/12/89)
In article <30520@apple.Apple.COM> farrier@Apple.COM (Cary Farrier) writes: > change a JSR to a JSL *if* the destination address requires it! ^^^ ^^^ JMP JML Cary Farrier
shawn@pnet51.cts.com (Shawn Stanley) (05/17/89)
mattd@Apple.COM (Matt Deatherage) writes: >In article <1135@orbit.UUCP> shawn@pnet51.cts.com (Shawn Stanley) writes: >>Someone mentioned that a good assembler would change JMP to BRL during the >>assembly. (Actually, he said it would change JMP to JML, but we know what he >>meant. :-) > >No, I think he actually meant what he said. The point was that any assembler >worth it's salt is not so picky as to refuse to generate a long jump instruction >(usually abbreviated JML) if you force long addressing on a JMP. In other >words, a good assembler should generate the same code for JMP >LongOffset as it >would for JML LongOffset. > >(Now don't confuse my use of "offset" up there with thinking I really mean >"branch". I mean "jump". I'm just testing y'all.) Matt, the JML instruction is absolute indirect. You may only: JML (16-bit_address) It then takes the three-byte address from the 16-bit address in the current program bank. There is a form of the JMP instruction that is absolute long. Here's an outline of some JMP forms and why they can't be changed to JML by the assembler: absolute JMP addr16 JML is only absolute indirect absolute long JMP addr24 JML is only absolute indirect absolute indirect JMP (addr16) JML requires a 3rd byte at addr16+2 for the new program bank Also, there is no absolute indexed indirect version of JML, which is one reason why JMP (addr16,X) can't be changed. The other reason is that as in the case of absolute indirect, JML requires a 3rd byte at addr16+2 for the new program bank. UUCP: {uunet!rosevax, amdahl!bungia, chinet, killer}!orbit!pnet51!shawn INET: shawn@pnet51.cts.com
shawn@pnet51.cts.com (Shawn Stanley) (05/17/89)
farrier@Apple.COM (Cary Farrier) writes: >In article <1135@orbit.UUCP> shawn@pnet51.cts.com (Shawn Stanley) writes: >>Someone mentioned that a good assembler would change JMP to BRL during the >>assembly. (Actually, he said it would change JMP to JML, but we know what he >>meant. :-) Again, I would hope not. Optimizing assemblers aren't for me; if >>I enter something, I *mean* that something. And a mod from JMP to BRL, >>although it seems harmless, will actually cause problems if you use >>self-modifying code. > > WRONG! Like you, I *mean* what I say. I said a good assembler will > change a JSR to a JSL *if* the destination address requires it! > Please don't put words into other peoples mouths just to make your > point. Cary, was it you that I was referring to? If I remember correctly (and I might not), your comment was part of a JMP/BRL conversation. I think it's possible that you meant to say JSR/JSL and instead said JMP/JML. Or, I was confused and *thought* you were talking about JMP/JML, in which case I apologize profusely and can't imagine what came over me that day. (I might not remember everything, but I rarely misread a message. Unfortunately, I don't have a copy of the original message and can't say either way for sure.) And to clarify a point, as soon as I understood that the conversation was actually about JMP/BRL instead of JMP/JML (with the author having stated that he actually *did* mean BRL and not JML), I also thought I understood a point about the (alleged?) JMP/JML conversation, and foolishly attempted to respond without a copy of the original message at my disposal. Always a risky thing to do. I did not attempt to put words into your mouth. One of us was confused, and as I said, I apologize if it was me. But neither should you attempt to put motives into my expressions. I wasn't disfiguring what you said to make some imagined or real point. UUCP: {uunet!rosevax, amdahl!bungia, chinet, killer}!orbit!pnet51!shawn INET: shawn@pnet51.cts.com
shawn@pnet51.cts.com (Shawn Stanley) (05/17/89)
farrier@Apple.COM (Cary Farrier) writes: >In article <30520@apple.Apple.COM> farrier@Apple.COM (Cary Farrier) writes: >> change a JSR to a JSL *if* the destination address requires it! > ^^^ ^^^ > JMP JML Again, I apologize. I was confused, and did not have the original at my disposal. (I wasn't putting words into your mouth to make a point.) UUCP: {uunet!rosevax, amdahl!bungia, chinet, killer}!orbit!pnet51!shawn INET: shawn@pnet51.cts.com
mattd@Apple.COM (Matt Deatherage) (05/18/89)
>Matt, the JML instruction is absolute indirect. You may only: > JML (16-bit_address) > >It then takes the three-byte address from the 16-bit address in the current >program bank. > >There is a form of the JMP instruction that is absolute long. Here's an >outline of some JMP forms and why they can't be changed to JML by the >assembler: > >absolute JMP addr16 JML is only absolute indirect >absolute long JMP addr24 JML is only absolute indirect >absolute indirect JMP (addr16) JML requires a 3rd byte at > addr16+2 for the new program > bank > >Also, there is no absolute indexed indirect version of JML, which is one >reason why JMP (addr16,X) can't be changed. The other reason is that as in >the case of absolute indirect, JML requires a 3rd byte at addr16+2 for the new >program bank. > >UUCP: {uunet!rosevax, amdahl!bungia, chinet, killer}!orbit!pnet51!shawn >INET: shawn@pnet51.cts.com (Sorry I lost the "he writes" line.) This simply isn't true. Most references I've seen say JMP and JML ar alternate forms of the same opcode, with JML forcing long addressing. The Eyes and Lichty books list JML as an alternate form of JMP for all instances where the addressing being jumped through (absolute or effective) is three bytes long. I'm not saying you don't have a reference that says what you say; I'm saying that common usage is exactly the opposite. Common usage doesn't limit JML to one form, making it different from JMP. In fact, assemble some code and then list it in the monitor, and see what opcode it puts beside it. ----------------------------------------------------------------------------- Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome Send PERSONAL mail ONLY (please) to: | should not be construed to imply that AppleLink PE: Matt DTS GEnie: AIIDTS | Apple Computer, Inc., or any of its CompuServe: 76703,3030 | subsidiaries, in whole or in part, Usenet: mattd@apple.com | have any opinion on any subject." UUCP: (other stuff)!ames!apple!mattd | "So there." -----------------------------------------------------------------------------