Herbert Kleebauer wrote:
>    But from a marketing point of view it is much better to
>    say, AVR has 32 registers and a separate IO address space 
>    than say it correctly:

The registers are in the register file which is
a small RAM.

The separate I/O address apage is just marketer's fog
into the customer's eyes.

In the same way, there are multiple names for
the same basic instructions. It took some time
for me to decode.

The processor architecture is better than the desription.

> The fundamental characteristic of a RISC architecture is,
> that only load/store instruction can access memory. In the
> AVR architecture all ALU operation are performed on the
> first 32 memory locations. Therefore I wouldn't call the AVR
> architecture a RISC architecture. It is a register less
> architecture with a short addressing mode for the zero 
> page.
> 
> Which RISC processors do you know, which have a memory
> mapped register set?

The registers have only memory mapped *images*. All
the normal register operations are performed with
register addressing.

When all the RAM is internal to the processor chip,
it's bloody difficult to tell which amount of
register array is just a register bank and which
amount is then memory used as registers.

If the registers were regarded as a special zero page
(without the traditional zero-page uses a la PDP-8),
the instruction set would be described as a mess.

The main effect of memory-mapping the registers
and I/O is loss of some of the memory addressing
capability.

To me, it's a pretty traditional RISC (without delay
slot problems) and extra possibility to index into
the register bank.

----

The asssembly code is different from e.g. PDP-11 or
Motorola 68xx and 68xxx, but it does not make it
worse. There are selections done which seem to
annoy you, but still there is no sense to fight
it and claim that the other way is better.

-- 

Tauno Voipio
tauno voipio (at) iki fi

Herbert Kleebauer <klee@unibwm.de> writes:
> Tauno Voipio wrote:
> > Herbert Kleebauer wrote:
>  
> > The registers are imaged in low memory addresses,
> > but there is an important difference: most operations
> > can use registers only. The plain memory locations can
> > be used with loads and stores only.
> 
> That's why I wrote:
> 
>    But from a marketing point of view it is much better to
>    say, AVR has 32 registers and a separate IO address space 
>    than say it correctly:
> 
>    AVR doesn't have any registers and we have to use a part
>    of the memory address space for addressing the IO registers
>    and all the ALU operations like add, and, or, ... are
>    restricted to the first 32 memory locations (or if immediate
>    operands are used to the memory locations 16-31). The sad 
>    thing is, that because of this marketing trick we have to use 
>    a bad assembler syntax.
> 
> The AVR architecture allows an implementation with separate
> registers but can also implemented as a register less CPU with
> ALU operations restricted to the first 32 memory locations.
> I wouldn't be surprised if there are low cost versions (with
> a lower clock speed) which don't have hardware registers. But
> as I said, this are implementation details, the AVR architecture
> uses memory mapped "registers" and therefore no registers (and
> no IO instructions) are necessary in an AVR assembler.
>  
> > Please check again a good reference book on
> > RISC computer architectures.
> 
> The fundamental characteristic of a RISC architecture is,
> that only load/store instruction can access memory. In the
> AVR architecture all ALU operation are performed on the
> first 32 memory locations. Therefore I wouldn't call the AVR
> architecture a RISC architecture. It is a register less
> architecture with a short addressing mode for the zero 
> page.
> 
> Which RISC processors do you know, which have a memory
> mapped register set?

Registers are logically just fast memory with a short form
of addressing and predefined "names".  There are usually
arithmetic and logical operations that can be performed
on registers that can't be performed (directly) on other
locations.  The AVR happens to map the "registers" to
memory locations (as a number of other processors have
done over the years).

Tauno Voipio wrote:
> Herbert Kleebauer wrote:

 
> The registers are imaged in low memory addresses,
> but there is an important difference: most operations
> can use registers only. The plain memory locations can
> be used with loads and stores only.

That's why I wrote:

   But from a marketing point of view it is much better to
   say, AVR has 32 registers and a separate IO address space 
   than say it correctly:

   AVR doesn't have any registers and we have to use a part
   of the memory address space for addressing the IO registers
   and all the ALU operations like add, and, or, ... are
   restricted to the first 32 memory locations (or if immediate
   operands are used to the memory locations 16-31). The sad 
   thing is, that because of this marketing trick we have to use 
   a bad assembler syntax.

The AVR architecture allows an implementation with separate
registers but can also implemented as a register less CPU with
ALU operations restricted to the first 32 memory locations.
I wouldn't be surprised if there are low cost versions (with
a lower clock speed) which don't have hardware registers. But
as I said, this are implementation details, the AVR architecture
uses memory mapped "registers" and therefore no registers (and
no IO instructions) are necessary in an AVR assembler.
 
> Please check again a good reference book on
> RISC computer architectures.

The fundamental characteristic of a RISC architecture is,
that only load/store instruction can access memory. In the
AVR architecture all ALU operation are performed on the
first 32 memory locations. Therefore I wouldn't call the AVR
architecture a RISC architecture. It is a register less
architecture with a short addressing mode for the zero 
page.

Which RISC processors do you know, which have a memory
mapped register set?

Herbert Kleebauer wrote:
> Colin Paul Gloster wrote:
> 
>>Herbert Kleebauer wrote in news:42E4A9FF.2C21A3E9@unibwm.de
> 
>  
> 
>>If the assembly language would be well designed, we neither
>>had registers (r0-r31) nor an IO address space. A simple
>>"move adr1,adr2" would be sufficient. Depending on the
>>given address, the the assembler would generate the
>>correct opcode.
> 
> 
>  
> 
>>AVRs do have registers. Performing arithmetic on values stored only
>>in registers is quicker than performing arithmetic on values needed
>>from RAM or ROM.
> 
> 
> It is only an implementation detail whether the so called "registers"
> are implemented as FlipFlops or as the first part of the onchip SRAM.
> The AVR architecture doesn't have registers (an architecture is 
> independent of the actual implementation and an assembler is architecture
> specific but not implementation specific). The AVR "registers" are memory 
> mapped as is the IO.


The registers are imaged in low memory addresses,
but there is an important difference: most operations
can use registers only. The plain memory locations can
be used with loads and stores only.

Please check again a good reference book on
RISC computer architectures.

-- 

Tauno Voipio
tauno voipio (at) iki fi

Colin Paul Gloster wrote:
> Herbert Kleebauer wrote in news:42E4A9FF.2C21A3E9@unibwm.de
 
> If the assembly language would be well designed, we neither
> had registers (r0-r31) nor an IO address space. A simple
> "move adr1,adr2" would be sufficient. Depending on the
> given address, the the assembler would generate the
> correct opcode.

 
> AVRs do have registers. Performing arithmetic on values stored only
> in registers is quicker than performing arithmetic on values needed
> from RAM or ROM.

It is only an implementation detail whether the so called "registers"
are implemented as FlipFlops or as the first part of the onchip SRAM.
The AVR architecture doesn't have registers (an architecture is 
independent of the actual implementation and an assembler is architecture
specific but not implementation specific). The AVR "registers" are memory 
mapped as is the IO.

Jonathan Kirwan wrote:

"[..]

The above issue comes to the fore for me when developing on a tool
where I may not be able to legally restore the compiler toolset.  In
those cases, I try and avoid the tools in the first place.  An example
here happened in the case of tools from Analog Devices, where the
toolset was key-locked to the machine.  What happens to me, say 5 or 8
years later when a client asks me to make a small but important
feature addition?  I set about to recover my tools and source code
and, no longer having that exact machine with the exact same disk
drive, discover that I cannot operate the compiler, at all.  So I call
up Analog Devices for help.  And do you imagine that even they know
how to help me, after so much time has gone by? [..]

[..]"

Or from what happened to the European Space Agency, whether Analog Devices
would continue to provide contractually required support itself.

Herbert Kleebauer wrote in news:42E4A9FF.2C21A3E9@unibwm.de
timestamped Mon, 25 Jul 2005 10:59:43 +0200:

"[..]

If the assembly language would be well designed, we neither
had registers (r0-r31) nor an IO address space. A simple
"move adr1,adr2" would be sufficient. Depending on the
given address, the the assembler would generate the 
correct opcode.

But from a marketing point of view it is much better to
say, AVR has 32 registers and a separate IO address space 
than say it correctly:

AVR doesn't have any registers and we have to use a part
of the memory address space for addressing the IO registers
and all the ALU operations like add, and, or, ... are
restricted to the first 32 memory locations (or if immediate
operands are used to the memmory locatioons 16-31). The sad 
thing is, that because of this marketing trick we have to use 
a bad assembler syntax.

[..]"

AVRs do have registers. Performing arithmetic on values stored only
in registers is quicker than performing arithmetic on values needed
from RAM or ROM.

Herbert Kleebauer asked in news:42E27637.20DF264A@unibwm.de
timestamped Sat, 23 Jul 2005 18:54:16 +0200:

"[..]

[..] Are there AVR versions
which have support for hardware breakpoints[..]? [..]"

Yes.

On 24 Jul 2005 12:37:05 GMT, Hans-Bernhard Broeker
<broeker@physik.rwth-aachen.de> wrote:

>In comp.arch.embedded wolfgang kern <nowhere@nevernet.at> wrote:
[...]
>> That's new to me, AT&T/gas/gcc/.. use Intel/AMD recommeded style? 
>
>No.  But I'm willing to forgive AT&T (and GNU, which borrowed their
>syntax) this violation of a well-founded principle, on the grounds
>that Intel's original x86 assembly language is so incredibly horrible.

I might be able to extend the same forgiveness, were it not for the
fact that AT&T/gas is so much _worse_.

FWIW, back when I did a lot of x86 assembler, I used TASM's IDEAL mode
for any code I wrote, and its MASM emulation mode (sans QUIRKS) for
assembling third-party code (if it had needed QUIRKS, I probably would
have re-written it).  I used Metaware High-C for C code, and avoided
gas/gcc altogether.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Betov wrote:
> CBFalconer <cbfalconer@yahoo.com> &#4294967295;crivait
>> Betov wrote:
>>> William Meyer <wmeyer@sbcglobal.net> &#4294967295;crivait news:
>>>
>>>> If you've nothing of substance to contribute to the ongoing debate on
>>>> what constitutes a "real" implementation of an X86 assembly language
>>>> tool, I'm sure I am not alone in hoping you will merely observe.
>>>
>>> If someone can translate this strange sentence in english...
>>
>> Your inability to parse a perfectly clear English sentence is not
>> our responsibility.  However, Mr. Meyers hopes have apparently not
>> been met.
> 
> Sorry, but the above sentence members do not make any sense
> to me:
> 
... snip 70 odd lines of raving ...

PLONK

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!