Writing an assembly language program for ARM7TDMI to count the number of 0's and 1's in the number 01113. I need to store the number of 0's in register R0 and the number of 1's in register R1.
I am constantly getting this one error, And I am not able to locate from where is this error coming. Please give some suggestion.

 

That is a poor assembler if it cannot tell you the type of error and line number of the error.
Can you print out the assembler listing?

 

The code won't work - it just checks the LSB every time.
Do you need to state somewhere that it is ARM7, not thumb and not some cortex version?
Are you sure about the "LDR R4,=my_constant" line? That usually tells it to store the value of my_constant in the program and then load it referenced to the PC. As it is written it may load into R4 the address of the label "my_constant" not the value declared in the DCD line.
Assemblers differ - I'm used to GNU AS and this isn't GNU AS.

This is simpler:

MOV R0,#0
MOV R1,#0
MOV R2,#32
LDR R4,=my_constant
LOOP:
LSRS R4,R4,#1
ITE CC*
ADDCC R0,R0,#1
ADDCS R1,R1,#1
SUBS R2,R2,#1
BNE LOOP

* for genuine ARM7 (not thumb or cortex, you don't need this line)

 

That is a poor assembler if it cannot tell you the type of error and line number of the error.
Can you print out the assembler listing?

No matter what changes I do, I am getting this following error.
"error: L6236E: No section matches selector - no section to be FIRST/LAST.
Not enough information to list image symbols.
Not enough information to list load addresses in the image map."
How to get rid of this?? any idea

 

No matter what changes I do, I am getting this following error.
"error: L6236E: No section matches selector - no section to be FIRST/LAST.
Not enough information to list image symbols.
Not enough information to list load addresses in the image map."
How to get rid of this?? any idea

It would appear to be something to do with memory allocation. See other working examples on how to specify code and data area.

Try adding after the ENTRY directive
EXPORT START

 

The code won't work - it just checks the LSB every time.
Do you need to state somewhere that it is ARM7, not thumb and not some cortex version?
Are you sure about the "LDR R4,=my_constant" line? That usually tells it to store the value of my_constant in the program and then load it referenced to the PC. As it is written it may load into R4 the address of the label "my_constant" not the value declared in the DCD line.
Assemblers differ - I'm used to GNU AS and this isn't GNU AS.

This is simpler:

MOV R0,#0
MOV R1,#0
MOV R2,#32
LDR R4,=my_constant
LOOP:
LSRS R4,R4,#1
ITE CC*
ADDCC R0,R0,#1
ADDCS R1,R1,#1
SUBS R2,R2,#1
BNE LOOP

* for genuine ARM7 (not thumb or cortex, you don't need this line)

No matter what changes I do, I am getting this following error.
"error: L6236E: No section matches selector - no section to be FIRST/LAST.
Not enough information to list image symbols.
Not enough information to list load addresses in the image map."
How to get rid of this?? any idea

 

It would appear to be something to do with memory allocation. See other working examples on how to specify code and data area.

Try adding after the ENTRY directive
EXPORT START

I
Any idea on this. the error was pointing to this specific step *.o (RESET, +First) of the following
; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************

LR_IROM1 0x00000000 0x00080000 { ; load region size_region
ER_IROM1 0x00000000 0x00080000 { ; load address = execution address
*.o (RESET, +First)
*(InRoot$$Sections)
.ANY (+RO)
.ANY (+XO)
}
RW_IRAM1 0x40000000 0x00008000 { ; RW data
.ANY (+RW +ZI)
}
}

 

Remove all the instructions in the code between START and STOP.
Then see what error you get.

 

https://developer.arm.com/documenta...-Instructions/CNT--Population-Count-per-byte-

 

Here an interesting little article all about this.

 

What about a small lookup table? 16 entries. Each entry would be the number (0 thru 15) and the number of bits that number uses. Then simply pull 4 bits at a time from the source value and get the bit count from the table, the sum of all the 1s will be the sum of each of these bit counts.

So for a 16 bit number you'd count the bits in bit 0-3, then count the bits in bits 4-7 and so on.

Here's the data:

 

What about a small lookup table? 16 entries. Each entry would be the number (0 thru 15) and the number of bits that number uses. Then simply pull 4 bits at a time from the source value and get the bit count from the table, the sum of all the 1s will be the sum of each of these bit counts.

So for a 16 bit number you'd count the bits in bit 0-3, then count the bits in bits 4-7 and so on.

Here's the data:

View attachment 315757

Your binary values from 1 to 7 are wrong. For example, you show the same binary for 1, 4 and 8.

 

Your binary values from 1 to 7 are wrong. For example, you show the same binary for 1, 4 and 8.

It's a bit count for some sort of a hashing function.
https://en.wikipedia.org/wiki/Hamming_weight

Programmers being clever instead of clear, geeze!

 

Your binary values from 1 to 7 are wrong. For example, you show the same binary for 1, 4 and 8.

Your are correct sir, I do, so hate, computers!



Here's the C# source for this (I'd used PadRight instead of PadLeft!)

namespace ConsoleApp3
{
    internal class Program
    {
       static Dictionary<Byte,int> map = new Dictionary<Byte,int>();
       static void Main(string[] args)
        {
            for (Byte a = 0; a < 256; a++)
            {
                var s = Convert.ToString(a, 2).PadLeft(4,'0');
                var c = s.Count(ch => ch == '1');
                Console.WriteLine($"{s} ({a},{c})");
                map.Add(a, c);
                if (a == 255)
                    break;
            }
        }
    }
}

 

Your are correct sir, I do, so hate, computers!

I thought you were a master at low level computing.

 

I thought you were a master at low level computing.

I do not recall making such a claim Sir, I have some real world experience it's true but no more than some others here I'm sure.

3D Computer Graphics. (Page 36)

and again, Wireless World



and of course ETI (Electronics Today International)



Oh and it almost slipped my mind, how silly of me

QuickStudy C# Programming