Assembler: suggestions?

Projects Programming
1

Hi everybody.

Since a few weeks I'm totally into Assembler. It's a new adventure to me since I have no experience at all with assembler, not even on another processor family.

Anyway, I already started studying and coding. I'm quite confortable now with the very (very!) basics, I'm using Atmel Studio 6, I upload my hex code to a few Atmega328 and Attiny (various versions) chips on breadboard with an USBASP ISP programmer and everything runs fine :slight_smile:

I make myself clear right now: I'm not planning anything specific yet; it's just fun and learning as of now :slight_smile:

Well, fact is I'd like to dig into it even more, I see many people are using c/c++ only (and of course I can understand why) and not many sharing knowledge about avr assembly ... I'm shure I'm missing something. Any forum/webring/book/newsgroup I don't know and you reckon I should?

I'm already constantly reading/studying:

But ... I can't find any updated AVR Assembly related forum :frowning:

2

Personal opinion here and thats all, but it might be because C is reasonably close to the metal to begin with and the extra effort and repetition writing assembly does not pay off in the majority of cases.

a++;

Thats 12 lines of assembly right there, its not interesting, its not challenging, its generally pretty tedious.

Just personal opinion from someone who was very excited about learning assembly a few short months ago but has since formed the opinion above. Spend your time writing something amazing rather than writing code that the compiler can generate for you - I probably have fewer years ahead of me than you so this might just be relevant to us older folks.

Duane B.

rcarduino.blogspot.com

3

Assembly can be intriguing at times. I'm definitely not a fan of it either, but one nice side effect of learning it is you gain quite a deep knowledge of the uP you're working with. When (eventually) you come back to C/C++, you better understand why certain things happen or how to manipulate the hardware at a lower level than digitalRead(), in case you need it.

I've worked a bit with asm on PIC processors (with code written by others and some written by me), and a lot with C on the 18F family.
While I wouldn't certainly exchange C with ASM, dealing with the latter also meant dealing with far more hardware related issues than I usually feel comfortable with. It's been interesting, at least.

(...now what was that protected child classes all about ? :stuck_out_tongue: )

PS: There's also that asm-inlined-in-C-code thing...

4

DuaneB:
a++;

Thats 12 lines of assembly right there, its not interesting, its not challenging, its generally pretty tedious.

I understand your point, but that damn Blink c/c++ sketch is going to compile a "huge" 1084bytes against a couple dozen when coded in pure asm!

Anyway, you see, that's not the point to me. I'm not looking for efficiency or performance, I'm just learning.
I'd like to gain some confidence with assembler coding, the Atmel processors are of great help since they're not too much complicated and there are quite a few people (thanks to Arduino) that are developing on them ... and, above all, I'm having fun with it :slight_smile:

5

tuxduino:
Assembly can be intriguing at times ... one nice side effect of learning it is you gain quite a deep knowledge of the uP you're working with. When (eventually) you come back to C/C++, you better understand why certain things happen or how to manipulate the hardware at a lower level than digitalRead(), in case you need it.

I may agree with that.
I'll let you know if that's my case when I get to have enough asm knowledge to be able to appreciate it when coding c/c++ again :slight_smile:

PS: There's also that asm-inlined-in-C-code thing...

I've read good and bad things about that. What's your opinion?

6

robitabu:

tuxduino:
Assembly can be intriguing at times ... one nice side effect of learning it is you gain quite a deep knowledge of the uP you're working with. When (eventually) you come back to C/C++, you better understand why certain things happen or how to manipulate the hardware at a lower level than digitalRead(), in case you need it.

I may agree with that.
I'll let you know if that's my case when I get to have enough asm knowledge to be able to appreciate it when coding c/c++ again :slight_smile:

PS: There's also that asm-inlined-in-C-code thing...

I've read good and bad things about that. What's your opinion?

I agree with this outlook. I enjoyed my introduction to machine language and assembly language when first working with minicomputers back in the 70s. It's that only way one can really learn how CPUs actually work with memory, registers, basic ALU functions, addressing modes, etc. However once mastered, if your target chip has a C/C++ cross compiler available then that is the BEST way to create useful applications for the chip even if you are programming with instruction abstractions of a high level programming language.

Lefty

7

16 tunes, 4 inputs, 8 bit visualizer (only 4 in the video, but its 8 now) - just over 2K compiled in the Arduino IDE - not bad for a high level language.

Lots of direct register access straight from C without having to mess around in assembly -

The entire visualizer code is -

unsigned char output = OCR0A;
 
 // clear visualiser bits on portD
 PORTD &= 0B000011; 

 // set the portd part of the visualiser using the top 4bits of output
 PORTD |= ((output>>4)<<2);
 
 // set the portc part of the visualiser using the bottom 4 bits of output
 PORTC &= 0B110000;
 PORTC |= (output & B1111);

PS - only the visualizer code is mine, most of it is based on this thread - http://arduino.cc/forum/index.php/topic,74123.0.html

Duane B

rcarduino.blogspot.com

8

DuaneB:
16 tunes, 4 inputs, 8 bit visualizer (only 4 in the video, but its 8 now) - just over 2K compiled in the Arduino IDE - not bad for a high level language.

Lots of direct register access straight from C without having to mess around in assembly -

Oh yeah, I've seen that coming! I knew you were going to show off XD

9

Sorry.

Not much of it is mine anyway, I only added half an hours work and uploaded a video.

See here -

http://arduino.cc/forum/index.php/topic,74123.0.html

and here

For the original work I am surfing on the back of

Duane B

10

robitabu:

PS: There's also that asm-inlined-in-C-code thing...

I've read good and bad things about that. What's your opinion?

I have very little experience with that. My (very humble) opinion is that you run the risk of working against compiler optimizations and function parameters passing mechanics, if you're not careful enough. I believe it makes sense to exploit peculiar features of a processor that are not (properly) addressed by the compiler backend. MMX, SSE and heavy SIMD-type workloads like image processing come to mind. (Now that I think about it, OpenCV could be a good place where to look if inline asm actually has a point :slight_smile: )

Using inline asm as an extreme performance optimization tool (I've read this somewhere...) is not so good after all since very often algorithmic optimization provide far better results.

My 21 (euro) cent.

11

DuaneB:
Sorry.

Oh no, don't be! I enjoyd the way you did it :smiley:

12

I've read good and bad things about that. What's your opinion?

How should I put this? I know, TOTALLY SUX.

It's OK for a few lines but I don't see how you could write a program with it.

Stick with AS6.

I was very experienced with ASM on several processor architectures from Intel x86 to Z80 and custom bit-slice processors. It's a lot of fun and TBH once you create a library of common functions you can write an application pretty quickly.

For practical purpose though these days I would stick with C, but as a learning excersize I think you will find it very useful.

Rob

13

People poo poo asm, and then post the stupidest of questions without bothering to search for previous post's

I've not done any avr asm but i'd like to give it a go, i've done plenty of pic asm and once you start to think logically it all makes sense, although pics on the whole only have 35 instructions to learn which helps alot

sure asm is a lot of work but who ever learnt anything from copy paste someone elses code?

14

P18F4550:
People poo poo asm, and then post the stupidest of questions without bothering to search for previous post's

I've not done any avr asm but i'd like to give it a go, i've done plenty of pic asm and once you start to think logically it all makes sense, although pics on the whole only have 35 instructions to learn which helps alot

sure asm is a lot of work but who ever learnt anything from copy paste someone elses code?

Sure, I've 'learnt' from that, that some people can actually write error free code that also actually works. That was the evidence I needed to make me keep trying. :smiley:

Lefty

15

robitabu:
I understand your point, but that damn Blink c/c++ sketch is going to compile a "huge" 1084bytes against a couple dozen when coded in pure asm!

Only because it incorporates a couple of libraries that make things easy for you. The library that handles timers for example (to do delay() ) and the library to do pinMode and digitalOut which allow you to turn pins on and off, where the pin numbers are known at run time, not compile time.

For example, using port manipulation you can get something that blinks down to 178 bytes:

int main() 
  {                
  DDRB |= _BV (5);    // pinMode 13, OUTPUT
  while (true)
    {
    PORTB |= _BV (5);  // pin 13 high
    PORTB &= ~_BV (5);  // pin 13 low
    }
  }  // end of main

This particular example doesn't have a delay in it, but it shows that it is the features of the libraries that take up program memory, not the fact that it is written in C.

Of the generated code in my example above, some is interrupt vectors (you'll need them anyway), some for stuff for C++ but the main function takes up this much space:

int main() 
  {                
  DDRB |= _BV (5);    // pinMode 13, OUTPUT
  a6:	25 9a       	sbi	0x04, 5	; 4
  while (true)
    {
    PORTB |= _BV (5);  // pin 13 high
  a8:	2d 9a       	sbi	0x05, 5	; 5
    PORTB &= ~_BV (5);  // pin 13 low
  aa:	2d 98       	cbi	0x05, 5	; 5
  ac:	fd cf       	rjmp	.-6      	; 0xa8 <main+0x2>

That's 8 bytes of code.

... against a couple dozen when coded in pure asm ...

Well my 8 bytes of code in C++ is less than your "couple of dozen" in pure asm.

By all means learn assembler. I learned various variants of it over my life, and it is useful to know. But don't do it because you think you can write tighter code than the compiler. In most cases you can't.

16

DuaneB:
Personal opinion here and thats all, but it might be because C is reasonably close to the metal to begin with and the extra effort and repetition writing assembly does not pay off in the majority of cases.

a++;

Thats 12 lines of assembly right there, its not interesting, its not challenging, its generally pretty tedious.

Gotta believe it. But how much of the tediousness is due to the RISC architecture where we get less functionality per instruction. I've only written assembler on CISC machines, but did a lot if it back in the day, and some non-trivial apps and code at that. But "a++;" would have been a single instruction on some of those machines.

Can someone with assembly language experience on both RISC and CISC machines comment?

17

Yes, but the likelihood is that the CISC machine (probably micro coded) would take slightly longer to do the post increment, and consume more power and silicon real-estate whilst doing it.

18

AWOL:
Yes, but the likelihood is that the CISC machine (probably micro coded) would take slightly longer to do the post increment, and consume more power and silicon real-estate whilst doing it.

Without a doubt, all other things being equal, which they hardly ever are :wink: but my point was only from the view of the programmer, my hypothesis being that coding assembler on a CISC machine is less tedious, possibly more productive, etc.

19

Probably, what's the rule of thumb? 1 bug for every 10 lines of code. Less lines, less bugs and less time, although I'm sure it's not a linear relationship between languages.

Rob

20

1 bug for every 10 lines of code. Less lines, less bugs and less time,

Not in my experience, I deliberately write code that is huge, long names for everything, lots of functions with meaningful names because I know the compiler will inline them, but also that more people will be able to read, understand and use the code.

Its also a lot easier on my fading memory when I need to revisit something.

Duane B