Path: utzoo!attcan!uunet!lll-winken!xanth!nic.MR.NET!umn-cs!bungia!orbit!pnet51!shawn
From: shawn@pnet51.cts.com (Shawn Stanley)
Newsgroups: comp.sys.apple
Subject: Re: JMP/JML revisited...
Message-ID: <1135@orbit.UUCP>
Date: 11 May 89 15:10:00 GMT
Sender: root@orbit.UUCP
Organization: People-Net [pnet51], Minneapolis, MN.
Lines: 36

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