OK.
The basic issue as I see it with AVR is that the addresses are
split between "registers", "RAM", "I/O-space". And the use of
these spaces is not even consistent within each group. You have
-lower 16 registers
-high 16 registers
-low 32 I/O registers
-high 32 I/O registers
-160 extended I/O registers
-RAM (rest of memory, if available)
All these are different in regard to what instructions/operations that
works in each area.
I think there was some AVR model where there was multiple USART,
one in the old I/O-register area and one in the "extended I/O registers".
The old was setup using the usual instructions, and the new with load/store.
And on the PIC, of course, you always use the same instructions and same
operations no matter where in the available memory you are working.
> I mean could you for example add [two values].
On the PIC it is always done in the same way.
On the AVR it depends on where these values are stored.
-----Ursprungligt meddelande-----
Från: piclist-***@mit.edu <piclist-***@mit.edu> För smplx
Skickat: den 15 juli 2018 04:11
Till: Microcontroller discussion list - Public. <***@mit.edu>
Ämne: Re: SV: [PIC] RE: Xpress PIC16F18446 Evaluation Board
On Sat, 14 Jul 2018, Jan-Erik Söderholm wrote:
> OK, no reason to start a flame ware here, but... 😊
>
>> The Atmel instruction set is soooo much easier.
>
> It is not clear what you think is easier, but I have some issues to
> consider a 120+ instruction ISA "easier" then a 40 instruction ISA.
>
> And I consider having the same instructions to access *everything* in
> the PIC architecture "easier" then having to deal with different
> instructions for "registers" (and sometimes different if it is the
> lower or higher 16 regs), "RAM" and the "I/O address space".
>
> In a PIC you can directly do a "set/clear bit" instruction against
> *all* available memory (including all peripheral registers and I/O ports).
> Everything you can possible access is in the same flat (but banked)
> memory address map.
>
> The main reason for the 120+ instructions in the AVR is that it has an
> architecture that is divided between different types of storage.
> And each type has to some degree their own instructions.
>
> On an AVR you have SBR to set a bit (does it really toggle the bit ??)
> in a register, but only register 16-31, not the lower 16 registers.
>
> Or SBI to set a bit in the "lower 32 I/O registers - addresses 0-31".
> Note, not in the full 64 I/O regs or in the 160 "extended I/O regs".
> So it is a hit-n-miss if you happens to be able to use bit instruction
> against a specific peripheral register. If not, you have to copy to a
> register, do the bit-fiddling and copy back.
I think the problem here is not that "Atmel has 120+ instruction ISA" but that the assembler is dumb and does not generate different opcodes depending on the use of the instruction.
>
> Sometimes it feels like some people are more comfortable coming
> from "large" systems where you have "RAM" externally to the CPU
> and "registers" where you actually do the work, and that is what
> the AVR looks like, but internally.
>
> PIC on the other hand has *one* common way to access things no
> matter what it is called. On a PIC with 2 Kbytes, you have (in AVR
> terms) 2K "registers" that works like the 16/32 (depending in what
> you want to do) "registers" on an AVR.
Yes and some people (I include myself here) feel that an MCU that claims
to have 2K registers when it is clearly just internal RAM is just a
marketing gimick. Come on be honest how many of these PIC registers can
normally be used as source and destination in one instruction (that is
without going through W). I mean could you for example add R27 to R143.
Yes I know about movff but that's a special case.
>
> On a PIC you can do INC/DEC/SBF/CBF/whatever on *any* memory.
"memory"? Oops... Are you seeing these registers as RAM :-)
> The only instructions a large part of the AVR memory (the "RAM")
> understands is LOAD/STORE.
>
> Just the fact that it is enough with 40 instructions instead of 120+ is
> enough of a proof of a cleaner and "nicer" architecture.
Sorry Jan but this really is not proof. Consider the following Z80 and
8080 instructions
e.g.
8080 Z80
==== ===
LDA mem LD A,(mem)
STA mem LD (mem),A
MOV A,B LD A,B
MVI A,123 LD A,123
MVI M,123 LD (HL),123
LHLD mem LD HL,(mem)
SHLD mem LD (mem),HL
MOV A,M LD A,(HL)
MOV M,A LD (HL),A
LDAX B LD A,(BC)
STAX B LD (BC),A
LXI B,123 LD (BC),123
ADD B ADD A,B
ADI 123 ADD A,123
ADD M ADD A,(HL)
DAD B ADD HL,BC
DAD D ADD HL,DE
INR A INC A
INR M INC (HL)
INX B INC BC
INX D INC DE
In the above example there are 14 distinct 8080 nmemonics and 3 distinct
Z80 nmemonics and the examples given generate the exact same binary.
The point I am trying to make is that the Z80 code looks a great deal more
consistant than the 8080 code even though there are huge holes in it
e.g. "LD (HL),(BC)" is illegal and does not generate any code.
So turning this on it's head, I am sure a better Atmel assembler could
easily be used to greatly reduce the number of visible opcodes and make
the MCU feel nicer :-)
Friendly Regards
Sergio Masci
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mai