Still editing the syntax at the moment, and wondered if I'm on the right
track. I'm simply building and editing until all the errors go away.

Basically;
- I'll need to attend to some new SFR's, and some name changes
- Interrupts can be split to high and low priority
- I intend to use Bank1 of ram, so;
- my Cblock starts at 0x100
- all my old FSR and INDF become FSR1 and INDF1
- many of the 'goto's become 'bra' (within branch limits)

What I'm unsure of is:
- in the old code I had; goto $ + 5
- in the new code do I have to use; bra $ + 5
but I still get: "Warning 226: Destination address must be word aligned"
what do I do to alleviate this? The manual say's

"
226 UNKNOWN WARNING
A warning has occurred which the assembler cannot understand. It is not any
of the warnings described in this appendix. Contact your Microchip Field
Application Engineer (FAE) if you cannot debug this warning.
"

> Hi All
>
> I'm moving an assembly program from a 16F877 to a 18F452
>
> Still editing the syntax at the moment, and wondered if I'm on the right
> track. I'm simply building and editing until all the errors go away.
>
> Basically;
> - I'll need to attend to some new SFR's, and some name changes
> - Interrupts can be split to high and low priority
> - I intend to use Bank1 of ram, so;
> - my Cblock starts at 0x100
> - all my old FSR and INDF become FSR1 and INDF1
> - many of the 'goto's become 'bra' (within branch limits)
>
> What I'm unsure of is:
> - in the old code I had; goto $ + 5
> - in the new code do I have to use; bra $ + 5
> but I still get: "Warning 226: Destination address must be word aligned"
> what do I do to alleviate this? The manual say's

The 18F series has a byte addressed PC. But each op code is 2 bytes.
Therefore EVERY op code MUST start on a word boundary.

People will correct me if I'm wrong but to get the same functionality
use bra $ + 0x0a

However, I personally don't like this type of jumping and would much
rather see the use of a label. TTYL

>What I'm unsure of is:
>- in the old code I had; goto $ + 5
>- in the new code do I have to use; bra $ + 5
>but I still get: "Warning 226: Destination address must be word aligned"
>what do I do to alleviate this?
>
>
>
To quote a post from Jan-Erik in the "Linker Error" thread earlier this
month...

"One the 16-line of PIC's the program counter counts program
"words". That is, each single increment of the PC points to a
valid (14-bit) instruction.

On the 18-line of PIC's the program counter counts "bytes", and
two bytes makes up one 16-bit instruction. That is, when referencing
valid instructions, the LSB of the PC must be zero "0". The byte
adressing is used when reading/writing tables in program space
using the TBLxxx instructions.

Now, with that said, I can't tell how this relates to your code, since
you don't show enough of it to tell.

The most common case when porting "jump tables" from the 16
to the 18-line, is to multiply the "index" with two before adding
it to the PCL. Such as a simple shift left..."

> Hi All
>
> I'm moving an assembly program from a 16F877 to a 18F452
>
> Still editing the syntax at the moment, and wondered if I'm
> on the right track. I'm simply building and editing until all
> the errors go away.

Might be OK, if you just need a "working" prog.
It will probably not be "18-optimized" though...

>
> Basically;
> - I'll need to attend to some new SFR's, and some name changes

Obviously, yes... :-)

> - Interrupts can be split to high and low priority

But just becuse you can, do you need that ? From what I
have understod, most just use the single level interrupt system.

> - I intend to use Bank1 of ram, so;

Why ? Are you not using (the lower half of) bank0 at all ?
If so, you miss the whole "access bank" thing. That is one
of the realy nice things with the 18-line.

> - my Cblock starts at 0x100

I bet *someone* will add that you *should* look at RES and
use the linker instead... :-) You don't have to do that, but I would...

> - all my old FSR and INDF become FSR1 and INDF1
> - many of the 'goto's become 'bra' (within branch limits)
>
> What I'm unsure of is:
> - in the old code I had; goto $ + 5

Do yourself a big favour and throw them out at once !
Add lables and goto (or branch) to them instead. If you
had done that in your PIC16 code in the first place, that
had been portable as-is.

> - in the new code do I have to use; bra $ + 5
> but I still get: "Warning 226: Destination address must be
> word aligned"

Correct. As expected. Since each instruction is on an even
address, and you are adding an odd value, you will end up
on an odd address, right ? "even" + "odd" = "odd"...

> what do I do to alleviate this? The manual say's
>
> "
> 226 UNKNOWN WARNING
> A warning has occurred which the assembler cannot understand.
> It is not any
> of the warnings described in this appendix. Contact your
> Microchip Field
> Application Engineer (FAE) if you cannot debug this warning.
> "

Don't bother. Just get those goto/bra $-something out and
add lables instead.

> Any other common snags to watch for?

The rotate instructions, if I'm not wrong.
I think there are som changes how the carry bit is handled
in some arithmetic instruction, but I'm not sure...

>What I'm unsure of is:
>- in the old code I had; goto $ + 5
>- in the new code do I have to use; bra $ + 5
>but I still get: "Warning 226: Destination address must be word aligned"

To answer my own question courtesy of Roy in a previous post;

______________
"
Found this at a microchip forum -

It sounds like you have a 'goto $-1' or similar instruction somewhere in
the module. While that's legal in the 16-series devices, it's not for
the 18-series. In the 18-series devices, all PC-relative branches have
to be made to a location that's an even number of bytes from the current
PC value.

Rewriting the GOTO instruction fixed the linker error.

Posted this for any other PIC list members who may be converting PIC16
code to PIC18
_______________________________________
Roy
Tauranga
New Zealand
____________________________________

> What I'm unsure of is:
> - in the old code I had; goto $ + 5
> - in the new code do I have to use; bra $ + 5
> but I still get: "Warning 226: Destination address must be word aligned"
> what do I do to alleviate this? The manual say's

Well, it'd be nicest to use labels... The shortest instruction is 2 bytes
long, so you'd have to do something like $ + 2*5. Some instructions are
longer, though, so this can be dangerous. Nicest to just let the assembler
handle it through labels.

In computed gotos, I often have a variable holding the state. This needs
to be shifted left one bit (multiplied by 2) before adding to the pcl if
the table is branch instructions. A goto is longer, so a larger multipier
is needed.

I recall there also being a difference in the way flags are handled on
incf and decf instructions that causes some code to break. Look at those
carefully.

At 04:25 PM 22/02/2005 -0500, you wrote:
>However, I personally don't like this type of jumping and would much
>rather see the use of a label. TTYL
>
>-----------------------------
>Herbert's PIC Stuff:

Yes, I appreciate that, but it's obvioulsy most oft used with a btfsc type
instruction to move usually no more than 6 instructions away. Labels in
these instances get messy and look superflous.

> >However, I personally don't like this type of jumping and would much
> >rather see the use of a label. TTYL
> >Herbert's PIC Stuff
>
> Yes, I appreciate that, but it's obvioulsy most oft used with
> a btfsc type instruction to move usually no more than 6
> instructions away. Labels in these instances get messy
> and look superflous.

The use of lables instead of the $+/- thing just
tells me that the code was written by someone
who cares about future management of the code and
that maybe someone else will be reading it also.

*AND*, it makes the code less portable, which actualy
was your problem here, right ?

At 11:10 PM 22/02/2005 +0100, you wrote:
>Roland wrote :
>
>> Hi All
>>
>> I'm moving an assembly program from a 16F877 to a 18F452
>>
>> Still editing the syntax at the moment, and wondered if I'm
>> on the right track. I'm simply building and editing until all
>> the errors go away.
>
>Might be OK, if you just need a "working" prog.
>It will probably not be "18-optimized" though...
>

Thanks Jan-Erik
I'll look into your pointers.
Yes, basically I've been absolute coding on the 877, and reached the first
page and bank limit.
Now I have to add to the program and was faced with further bank switching,
or going to re-locatable code, or going to the 18F. For a few cents more I
get linear address and 32K!! (Hah!, the foundation of all bloat code)

So right now I'm just aiming at workability to finish it off. I'll take the
18F manual to bed next month.

On Wed, 2005-02-23 at 01:04 +0000, Roland wrote:
> At 04:25 PM 22/02/2005 -0500, you wrote:
> >However, I personally don't like this type of jumping and would much
> >rather see the use of a label. TTYL
> >
> >-----------------------------
> >Herbert's PIC Stuff:
>
> Yes, I appreciate that, but it's obvioulsy most oft used with a btfsc type
> instruction to move usually no more than 6 instructions away. Labels in
> these instances get messy and look superflous.

Until of course another person comes to your code (or you many years
later), adds a single line, and BOOM, the whole things stops working.
Then weeks are spent trying to figure out why the UART isn't working.
After all, the addition of one line in the printf routine certainly
can't effect the UART spiting out weird stuff, right??

Sorry, I don't care how "superfluous" it might look, labels are
ESSENTIAL in my mind. TTYL

Jan-Erik Soderholm wrote:
> The rotate instructions, if I'm not wrong.
> I think there are som changes how the carry bit is handled
> in some arithmetic instruction, but I'm not sure...

The PIC 16 always rotates thru the carry bit. On the PIC 18 there are two
rotate instructions for each direction, one that rotates thru C and one that
doesn't. The dumb thing is that they changed the mnemonic for the one that
does, even though the instruction does the same thing. At least the
assembler will find all the rotates so you can manuall change them.

The nasiest difference is that the DECF and INCF instruction now have
different effect on the status bits. I think the PIC 18 way is better, but
the same mnemonics have different effects on the 16 adn 18.

I don't understand why they needed to make a new mnemonic for the rotate
instruction that does the same thing, but keep the same mnemonic for the
DECF and INCF instruction that do something different.

Roland wrote:
> Yes, I appreciate that, but it's obvioulsy most oft used with a btfsc
> type instruction to move usually no more than 6 instructions away.

That's about 5 instructions too far. It is very easy to slip some extra
instructions between the GOTO and the target in later without noticing the
jump around them. There is also no label at the target to warn you that
execution could be coming from multiple directions. This is irreresponsible
programming at its worst.

> Labels in these instances get messy and look superflous.

They won't after you've wasted a day chasing an obscure bug a year from now
after a minor modification.

>As I recall from my early days of programming pics, one very
>pertinent reason for using $ as a PC designator was inside macros.
>With absolute code -which was the only source method available then-
>you couldn't put labels inside macros unless you were sure you only
>ever invoked them a maximum of once in your source file.
>Multiple invocations resulted in multiple same-labels and no assembly.
>So, the $ was the only way of looping within macros.
>
>When the linker mode came along, labels in macros were allowable
>provided you made them:
>
>Local yadayada, eieio ;yada.. eie... are label names.
>
>Thus the labels were dereferenced globally speaking and the
>macro could be invoked many times with `same' labels inside.
>With the 18F and linker there should no longer be ANY reason
>to mess with the $ bug-in-waiting.
>If you want to use absolute code and $ with the 18F, then you are
>deep into crocodiles.
>
>Any comments?
>

Well, how about "You are wrong?"

The fact is you can CAN have local labels in absolute 18F code and it has
nothing
to do with the linker.

Branch relatives with offsets of $+4, $-2 or in some cases $-4 are more
readable than
trying to spot matching labels that could be anywhere.

Any person who wants to tell me I cannot instantly recognize this snippets
of code is
wasting their time.

clrwdt
btfss BusyFlag
bra $-4

Anyone else who cannot reconize it has no business looking at my code. ;-)

>
>
> >As I recall from my early days of programming pics, one very
> >pertinent reason for using $ as a PC designator was inside macros.
> >If you want to use absolute code and $ with the 18F, then you are

> >deep into crocodiles.
> >
> >Any comments?
> >
>
> Well, how about "You are wrong?"
>
> The fact is you can CAN have local labels in absolute 18F code and it has
> nothing
> to do with the linker.

Fair enough, I've only used the 18Fs with the linker & hadn't checked
whether Locals could be used within absolute mode.

I'm still forever avoiding $ tho'.....
For the general un-maintainability & fragility reasons given by several others.