variable declration in 8051 assembly

Hi!
Can anyone tell me how to declare 8-bit or 16-bit variables while
programming in assembly language for 8051 microcontroller (AT89C51),
using the on-chip RAM.

Ammar wrote:

> Can anyone tell me how to declare 8-bit or 16-bit variables while
> programming in assembly language for 8051 microcontroller (AT89C51),
> using the on-chip RAM.

Can't be done, as assembly language doesn't really have the concept of a 
"variable", much less that of a 16-bit variable on an 8-bit microprocessor.

In other words: if you have to ask, you shouldn't be writing assembly 
code yet.  Stick with C for the time being.

"Hans-Bernhard Br&#4294967295;ker" <HBBroeker@t-online.de> wrote in message 
news:en914v$mn7$00$2@news.t-online.com...
> Can't be done, as assembly language doesn't really have the concept of a 
> "variable", much less that of a 16-bit variable on an 8-bit 
> microprocessor.
>
For the on-chip RAM I use EQU (equates) to define locations in direct and 
indirect space.  Granted, addresses must be assigned by hand, but given the 
typical small number of locations it isn't a problem.

For example:
X  EQU  60h
  MOV  A,X
  ADD   A,#4
  MOV  X,A

Syntax may vary by assembler.
  Jack Peacock 

Hans-Bernhard Br�ker wrote:
> Ammar wrote:
> 
>> Can anyone tell me how to declare 8-bit or 16-bit variables
>> while programming in assembly language for 8051 microcontroller
>> (AT89C51), using the on-chip RAM.
> 
> Can't be done, as assembly language doesn't really have the
> concept of a "variable", much less that of a 16-bit variable on
> an 8-bit microprocessor.
> 
> In other words: if you have to ask, you shouldn't be writing
> assembly code yet.  Stick with C for the time being.

Nonsense.  If you understand the underlying machine you can do
anything in assembly that you can do in C, and more.  However, it
won't be portable.

To answer the OP, there are usually pseudo instructions such as DS
(define storage) or DW (define word, i.e. initialized storage) or
DB (define byte, again initialized storage).  Placement of these
instructions is likely to be critical.  Read your assembler
documentation.  Read the manuals for your processor.  The
mnemnonics may not agree.

-- 
Merry Christmas, Happy Hanukah, Happy New Year
        Joyeux Noel, Bonne Annee.
Chuck F (cbfalconer at maineline dot net)
     <http://cbfalconer.home.att.net>

Jack Peacock wrote:

> For the on-chip RAM I use EQU (equates) to define locations in direct and 
> indirect space.  

Then you're making your life more miserable than hit has to be.  All 
8051 assemblers worth using have a DB pseudo-op that lets the 
assembler/linker take care of locations and their usage for you.

CBFalconer wrote:

> Nonsense.  If you understand the underlying machine you can do
> anything in assembly that you can do in C, and more.

While that's correct, it's not what I was talking about.  Assembly 
doesn't have variables, it only has symbols, i.e. named addresses.  That 
doesn't prevent a program written in assembly from using such concepts 
as "variables" --- but assembly language as such doesn't support them in 
any good sense of the word "support".

The crucial aspect missing is that assembler symbols don't really have a 
type.  Neither the 8051 nor the assembler care whether a given 
allocation of 4 bytes of data memory ("DS 4" in most 8051 assemblers) 
holds 32 individual bits, 4 bytes, 2 16-bit numbers a 3-byte generic 
pointer plus a flag byte, or something entirely different.  That's all 
up to the programmer.

A "DS 2" can be used as a part of the implementation of a 16-bit 
variable, but that doesn't mean it _is_ a 16-bit variable.

"Ammar" <ahaider7@gmail.com> wrote in message 
news:1167586359.524284.170250@a3g2000cwd.googlegroups.com...
> Hi!
> Can anyone tell me how to declare 8-bit or 16-bit variables while
> programming in assembly language for 8051 microcontroller (AT89C51),
> using the on-chip RAM.

The free SesAsm51 assembler implements types and sizes. You may declare 
variables of any byte sizes in any of the 8051 memory spaces.

Here's a download address: 
http://www.programmersheaven.com/zone5/cat780/index.htm

Happy New Year!

"Hans-Bernhard Br&#4294967295;ker" <HBBroeker@t-online.de> wrote in message 
news:enb7bv$fbe$02$1@news.t-online.com...
> Then you're making your life more miserable than hit has to be.  All 8051 
> assemblers worth using have a DB pseudo-op that lets the assembler/linker 
> take care of locations and their usage for you.

I use it as a way to track the different namespaces for RAM memory. and DS 
for external RAM, since there may be a large number of variables, and EQU 
for direct since it is a limited resource and I like to track each byte 
allocated.   It's a habit from the days of 8048 assembler.

On the other hand, with 8051's now having so much onboard flash and RAM, I 
try to do everything in C (SDCC-51 compiler) rather than assembler.
  Jack Peacock 

Hans-Bernhard_Br=F6ker?= <HBBroeker@t-online.de> writes:
> CBFalconer wrote:
> 
> > Nonsense.  If you understand the underlying machine you can do
> > anything in assembly that you can do in C, and more.
> 
> While that's correct, it's not what I was talking about.  Assembly 
> doesn't have variables, it only has symbols, i.e. named addresses.  That 
> doesn't prevent a program written in assembly from using such concepts 
> as "variables" --- but assembly language as such doesn't support them in 
> any good sense of the word "support".
> 
> The crucial aspect missing is that assembler symbols don't really have a 
> type.  Neither the 8051 nor the assembler care whether a given 
> allocation of 4 bytes of data memory ("DS 4" in most 8051 assemblers) 
> holds 32 individual bits, 4 bytes, 2 16-bit numbers a 3-byte generic 
> pointer plus a flag byte, or something entirely different.  That's all 
> up to the programmer.
> 
> A "DS 2" can be used as a part of the implementation of a 16-bit 
> variable, but that doesn't mean it _is_ a 16-bit variable.

We're splitting the hairs quite finely, aren't we?  It is
granted that ASMs don't know anything about data types,
sizes, allocation, etc., but ASMs provide the mechanisms
for the programmer to declare and access "variables".

On Mon, 01 Jan 2007 16:08:56 +0100, Hans-Bernhard Br�ker
<HBBroeker@t-online.de> wrote:

>CBFalconer wrote:
>
>> Nonsense.  If you understand the underlying machine you can do
>> anything in assembly that you can do in C, and more.
>
>While that's correct, it's not what I was talking about.  Assembly 
>doesn't have variables, it only has symbols, i.e. named addresses.  

These named addresses can have various attributes (at least in
relocating assemblers), some of which are inherited from the program
section in which the address is defined, such as program section name,
absolute/relocatable, RW/RO etc. It would not be too far to extend
this with byte/word/long attributes generated by BYTE/WORD/LONG
storage initialisation directives.

>That 
>doesn't prevent a program written in assembly from using such concepts 
>as "variables" --- but assembly language as such doesn't support them in 
>any good sense of the word "support".

Quite a few assemblers can select between short and long branches
based on the information of the program section and offsets within
sections. Some assemblers might be able to automatically generate
relative/absolute addressing modes depending of the attributes of the
target label. If the label carries some kind of byte/word information,
it would be possible for the programmer to use a generic MOV mnemonic
instead of explicit MOV_B/MOV_W opcode mnemonics.

>The crucial aspect missing is that assembler symbols don't really have a 
>type.  

What actually is a variable with a type ? Is it something radically
different from a symbol with attributes ?
 
>Neither the 8051 nor the assembler care whether a given 
>allocation of 4 bytes of data memory ("DS 4" in most 8051 assemblers) 
>holds 32 individual bits, 4 bytes, 2 16-bit numbers a 3-byte generic 
>pointer plus a flag byte, or something entirely different.  That's all 
>up to the programmer.

DS (Define Storage) is analogous to the memory allocation made
available by C malloc function, both representing a chunk of bytes,
although the malloc allocation requires an extra indirection to
access. You can do anything with the mallocated storage as you can do
with DS storage, as long as you stay within the allocation (for
processors with specific alignment rules for longer data types, the
allocation start must be located according to the alignment rules).

Paul