C or ASM?

Go To Last Post
150 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is kinda a weird question, dunno if it's been brought up before. Anyways, I'm really curious to learn assembly language just for the fun of it. Seems cool to me to work in a lower level. My fellow peers have told me that it's stupid for me to waste braincells though learning ASM if I already know C and can do stuff with it. Should I learn assembly just because I want to or would it ultimately just be a waste of time?? What's the biggest merit to doing projects in assembler over C? (I have a bad feeling about asking this question here, I hope I don't get yelled at too much...)

Thanks anyways

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
dunno if it's been brought up before
No, NEVER. :?

With ASM you can see the electrons flow inside the chip. Just go for it and ignore your fellow peers, they are only jealous and don't want you to become really good with micros.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cool, I'm gonna get some. Hope they got some good tutorials here or some well commented code. I'll find it.

js wrote:
they are only jealous and don't want you to become really good with micros.
I suspected assembly was the key to being boss with these little bad boys, I was told that learning assembler was dumb from a pretty C savvy person, didn't know if I shoulda believed him or not. I trust you though, never steered me wrong before :o

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It never hurts to learn the underlying architecture and instruction set. Knowing this can help you write better C code. So while you may never need to actually program in assembly, knowing how to do is is definitely of benefit.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Understanding assembly is very very important.

Using it in large complex applications where the exactness is not needed would be over-applying it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
My fellow peers have told me that it's stupid for me to waste braincells though learning ASM if I already know C

Your fellow peers are fools. There are cases where you absolutely need asm, and there are many cases where knowing asm can save your ass. What do your peers do when they are debugging an optimized C program and they run into a condition that the debugger can't match a breakpoint up to the original C (something that happens quite often)?

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ack, started reading on the avrbeginners.net website with the assembly. Looks pretty straight forward. Just had to make sure that I wasn't gonna be wasting my time by going on this little adventure. I'm convinced now, thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I suggest that if you already know C then focus on the ability to integrate assembler routines into your C code.

I'm assuming that the C referred to is a version of the language specifically oriented towards the AVR controller. C on the PC can be much different because the internal resources available on the PC are much greater.

Also try looking at the assembler code that is generated by simple routines in C.

I suspect that developers using assembler have learned microcontrollers (MCUs) from the electronics and logic circuits as electronic technicians and engineers. MCU developers using C I believe are coming into MCUs from a software background.

The smaller the MCU, the more likely it is to be programmed in assembler. Small AVRs like the Tiny11, tiny13, and the new 6-pin Tiny10 have too few internal resources like SRAM to support C code. But a skilled programmer can structure the C code to compensate for these issues.

I suspect also that the smaller number of devices that the MCU is going into, the more likely it is to be programmed in assembler. Test instruments for custom applications and so forth.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smkipus wrote:
(I have a bad feeling about asking this question here, I hope I don't get yelled at too much...)
But you brought it up anyway. Hmmmm...

Okay, so we are off on our monthly C vs ASM thread that will shortly break down into a flamewar. Fortunately, I've got my last 500 posts copied from that last 100 times we've done this, so I'll wait for it to all cook up a bit, then I'll jump in.

Hey, wait a minute... didn't we turn this into some sort of sticky?

Okay, can't wait.
To summarize, C is better than ASM because:
1. C is 10 times easier to use for writing a non-trivial program.
2. C is 100 times easier to debug.
3. C is 1000 times easier to maintain.
4. Nobody here is good enough at ASM to write a non trivial program that does a better job with ASM than the ASM generated by any old C compiler used by any old C programmer.
5. As soon as your idiot boss decides to switch from AVR to PIC, you do have a chance in Hell of porting your C code, but the chances of porting AVR ASM to PIC ASM are less than the chances of this thread staying civil.

But it isn't like I'm trying to be argumentative or anything.

Oh, and I'd never hire anyone that only knows C, I'd require in depth knowledge of at least one ASM. It's not like I'm a C bigot or anything.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:

4. Nobody here is good enough at ASM to write a non trivial program that does a better job with ASM than the ASM generated by any old C compiler used by any old C programmer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theatrus wrote:
Understanding assembly is very very important.

Using it in large complex applications where the exactness is not needed would be over-applying it.

Yes, that's it.
Need to know how to drive a manual shift car even though your cars use an automatic shift.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Worked on learning this all evening. Its a little tricky to me, having to use the inc file and the org statements and all this other fun new-to-me stuff. Wonderful IO/interrupts tutorial posted by avr freaks that helped me get going. This is going to be challenging though to do more than turn an LED off or on or use an interrupt. I finally get to use my numerical analysis math class for something practical: a floating point decimal system. Not sure how I'm going to mark where the decimal should reside yet though. Oh well, that's where I'm at.

Last Edited: Tue. Sep 15, 2009 - 04:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
floating point decimal system

BCD?

(now might be a good time to learn C)

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yah, I kinda got C figured out, assembly seems neat though cause its something I don't know well at all so I wanna see if I can do it just for the sake of it. Thanks though!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
To summarize, C is better than ASM because:

Apparently you didn't really read the OP completely. He was not asking if he should learn asm instead of C, but in addition to C.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When I decided to learn assembly it made my life better and my C more obfuscated (but faster).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
2. C is 100 times easier to debug.
I MUST remember that.
I MUST remember that.
I MUST remember that.
.
.
:lol:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
He was not asking if he should learn asm instead of C, but in addition to C.

Right you are - sorry. I was just thinking that implementing a BCD library might be an interesting first assembly language project.

As a couple of people here know, I'm actually a big fan of assembly language and think it should be required in any university programming sequence, but there are a couple of small things C is good for. Like floating point. And keeping Lee off the streets.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Never even heard of BCD was until I just read your post and googled it. I'm gonna give it a shot tonight

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
there are a couple of small things C is good for
Correct, it's ok for a trivial program but not to be taken too serious. :lol:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fraction multiplication or making and multiplying number less than 1 in assembly is possible? I'm googling assembly decimals and I'm getting all junk... What keyword should I search with?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

assembly language floating point gets you about 173,000 hits.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And as for the first part of your question (is it possible), it all comes down to assembly language (that is, the instruction set) in the end, so everything that can be done can be done in assembly language.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simonetta wrote:
Also try looking at the assembler code that is generated by simple routines in C.

How? I built a simple program to see how the c compiler does a float...

#include 

int main()
{
float testVAR;
return 0;
}

and I got a Hex,eep, elf, lss, map, 0, and a make file out of deal but no asm. Thanks for your patience with me

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you understand assembler, then you can look on the listfile to see, which expressions are easy and which are painful for the compiler.

Then you can write many times more efficient C-code as any pure C-programmer.

So learning assembler was no wasted time. :!:

Most tutorials for efficient C programming are based on assembler knowledge.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smkipus wrote:

Quote:
My fellow peers have told me that it's stupid for me to waste braincells though learning ASM

As far as I know, that's not really the way the brain works. Apparently it thrives on problem solving and mental exercise. Especially related to assembler and AVR. I believe thinking too hard about PICs or C++ can actually make you stupider, though.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Fraction multiplication or making and multiplying number less than 1 in assembly is possible?

If you want to divide and multiply using assembly
have a look at the following Atmel application note:

AVR200 Multiply and Divide Routines

It is even worth reading if you want to implement
high-precision or other special arithmetic using C.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does anyone actually use floating point stuff with micros? The few times I needed to work with numbers less than 1 I just multiply everything by 100 and I get 2 decimal points, whether in ASM or other strange languages.

Anyway most new AVRs have FMUL, FMULS, FMULSU if one is really that desperate.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe it has something to do with portability. Complex digital filters are easy to do if you have floating point enabled processor.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To my mind you cannot write C properly without understanding the underlying assembler that is being generated. For one thing, debugging optimised C is very tricky unless you use the mixed C+Asm view and doing that is a perfect way to gain familiarity with the Asm of the particular chip being used.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Does anyone actually use floating point stuff with micros?
Yes, I do, frequently. Floating point formats are very useful, but they do have to be treated with a bit of caution in several respects.

People often equate floating point with precision, but it is not as simple as that. A numeric representation may be characterised by its precision (Effectively, by how much must two real numbers differ to be distinguishable in the representation?) and dynamic range (Effectively, what is the ratio of the largest real number to the smallest real number that can be represented?).

Floats are an easy way to get 24-bit precision (longs give up to 32 bit precision, so are they "better"...?) without having to think too hard, but floats also provide you with huge dynamic range. Sometimes the dynamic range is as important (or more important) than the precision. While precision is attainable using scaled integers, attaining precision over a wide dynamic range may be difficult; you usually just end up reinventing floating point (or possibly a block floating point format, or...).

Floats are useful, but again, do treat with caution and make sure you understand how floating point works before using it in a critical application. This advice applies to work on "big" computers as well as to small ones.

Christopher Hicks
==

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was using assempbler for AVR for PIC and AVR for several years. I started using the IAR assembler and I wrote my macros and I used the same language for both of them. For example: I was writing
SkipIfSet
NoOpeartion
ResetWatchdog
Divide
e.t.c.

Then I tried to use the macros to write run time instructions like if, then and else, but I reached the limits of the IAR Assembler.

So I decided to use a higher level language. I tried the BASCOM, because I was almost a basic programmer, but I didn't like it, because it has the same characteristics of a classic interpreter. So I decided to sit and learn ANCI C.

Now, I can't believe how I was writing code in assembler for consumer and industrial products. Code up to 64Kb.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ASM and good hardware knowledge encourages you to do things with the micro that you may not have thought of doing, if all you new was high level stuff.

Example: It can be tricky to send 10bit SPI data (2 x 8bit) from a master to slave, when the slave is busy with time critical stuff and can't be interrupted.

I found a way by sending just the lower 8bits via SPI and then immediately outputing the 2 high order bits on the MOSI and SS lines. The slave can then read the 10bits at it's leasure, with 8 bits safe in SPDR and 2 bits safe in MOSI and SS port lines.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I found a way by sending just the lower 8bits via SPI and then immediately outputing the 2 high order bits on the MOSI and SS lines. The slave can then read the 10bits at it's leasure, with 8 bits safe in SPDR and 2 bits safe in MOSI and SS port lines.

Sorry but what's the difference whether you do that in C or Asm?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps my example wasn't too good. You do have a point.
But an ASM coder must know his hardware intimately, other wise he can't code.
Not all high level coders delve so obsessively into the harware. Not the ones I've met anyway.
My point was that the more you dig into the hardware, the more likely you are to discover new and better ways of doing things.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

But an ASM coder must know his hardware intimately, other wise he can't code.

If you replace "C" in place of "ASM" in that sentence how is the meaning changed?
Quote:

Not the ones I've met anyway.

Presumably not in a professional environment?

At the end of the day C is really just a high level macro language to write assembler (the point icarus1 was making I think?). The knowledge required of the hardware and the core CPU architecture are the same in both cases. A C programmer who never looks at the generated assembler is probably just "tinkering" not really programming.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
My fellow peers have told me that it's stupid for me to waste braincells though learning ASM if I already know C and can do stuff with it.

C or ASM is a cultural thing. When the majority program in C and the minority in ASM the ASM group will not be accepted by the C programmers and/or visa versa. (The same with AVR and PIC. Micro wars.) (ASM is vintage must be the thought? or?)
Learning is always good, it does not damage braincells, the more info the better. (input)

http://2.bp.blogspot.com/_qlCAUZ...

RES

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I program mostly in C, but I love to look at the assembly produced by the compiler. I wish I was as clever as it is. Sometimes I am and that is why I then I tweak things like using pointers instead of using array indexes during some process.

I find depending on where the code is the pointer is faster then using the array directly. Sometimes the opposite is true. This also can change with new releases of the compiler.

This allows me to see how the compiler optimizes things, and sometimes it can be improved where timing is critical.

Many times I will do a interrupt service routine in C first. Then grab the generated asm and improve it.

I agree that to know both languages is best. It allows you to get the most out of your processor and you can also see all the magic the compiler does and you can feel confident it will work as expected.

Just my 2 cents.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
A C programmer who never looks at the generated assembler is probably just "tinkering" not really programming.
I certainly agree in an embedded/microcontroller programming context, but I think the case is less clear cut when, for example, writing a unix mail server in C - as plenty of them are. An outline knowledge of how the compiler implements function calls, memory allocation and so on can be helpful, but is probably not essential. Taking into consideration the details of the specific registers and instruction set is probably inappropriate as good code (in that context) should be written to be reasonably portable, in my view.

But Cliff's right. An expert embedded software engineer requires an appreciation of electronic hardware, a thorough understanding of how microprocessors work and how the instruction set interacts with the hardware, and an ability to program fluently in assembler (of whatever flavour) and appropriate high level languages.

CH
==

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

but I think the case is less clear cut when, for example, writing a unix mail server in C

I was kind of expecting anyone reading this message board to be an embedded MCU programmer. It's true that when I write Windows GUI apps I never bother with the x86 Asm generated but you tend to program such systems with an "infinite resource" mentality meaning that there's probably more RAM and more CPU horsepower under the hood than you ever need care about. It's also pretty unusual to write a "realtime" GUI app (if nothing else neither Linux nor Win32 kernels offer "realtime" services)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Koshchi wrote:
Quote:
To summarize, C is better than ASM because:

Apparently you didn't really read the OP completely. He was not asking if he should learn asm instead of C, but in addition to C.

How did I misread when the title says s 'C or ASM' followed by this:

smkipus wrote:
What's the biggest merit to doing projects in assembler over C?
Given 'C or ASM' I'll go with C. And he says the 'biggest merit to doing projects in assembler over C?' Is not 'in addition to'. Given the OP, I'll stand by my post. IMHO, if you are just starting out and/or only intend to tinker (thanks Cliff) then go with C. If you aspire to really learning this stuff, especially the microcontroller architecture or want you to get a job, learn C and ASM.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From the OP:

Quote:
My fellow peers have told me that it's stupid for me to waste braincells though learning ASM if I already know C and can do stuff with it.

From that line I think that it is very clear that the OP already knows C and is asking whether to add asm to his repertoire, not learn asm instead of C.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, to take it to rediculous lengths, he says 'if' not 'since', but I'll withdraw with the suggestion that the OP change the title from 'C or ASM' to 'Learn ASM if I already know C?' My response to that OP would be 'yes'.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think the OP needs to pass the crucial pronunciation test of basic intergral storage types. Is it burned, does he give a damn, or is he going for a ride?

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Huh Chuck?

Anyways, yah I was wondering if I should add ASM to my repertoire and it seems that I should since everyone with 6 stars says yah. ASM + C = Job Potential. Sorry about the title of the post, I've only been tinkering for a couple years and its always been in C. I was wanting to get a better feel for what ASM is good for. I've learned from this thread that ASM is used when you have a small processor and want direct control with the program flow. I had thought that assembler was more or less a different language from C but now I understand that C is just a bunch of macros for ASM. I will definitely learn ASM since it seems crucial to the understanding of how embedded systems work.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Computer science grad:
"What namespace and class do I invoke to stop the white column of smoke rising from this embedded processor"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Huh Chuck?

Yeah, me too. There's a spirited discussion going on elsewhere over the correct pronunciation of "char." Don't let me influence you, but Smiley and I are right and most of the rest of the people here are wrong. But they're good folks other than that.

Learning assembly language is a Good Thing [tm] for a variety of reasons. The best is, it's fun.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
but now I understand that C is just a bunch of macros for ASM.

Some would say that, other wouldn't. It would be equivalent to saying that C++ is just a bunch of macros for C (which, in fact, it was originally).

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I use the GCC compiler with AVR studios/Win AVR. Is i possible to what the assembly looks like that my C code makes? I've heard people on this thread say take a peek at it but I don't know how since F7 doesn't generate an ASM file. How do i find out what my C code does in assembly?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And emacs is just a bunch of macros for TECO.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smkipus wrote:
So I use the GCC compiler with AVR studios/Win AVR. Is i possible to what the assembly looks like that my C code makes? I've heard people on this thread say take a peek at it but I don't know how since F7 doesn't generate an ASM file. How do i find out what my C code does in assembly?

You said you've got .lss. That's sort of it - it's a result of disassembling the binary, to be more precise, but it contains all you want.

You might also want to learn how to step through the code (the disassembled version, not the C source) in AVRStudio's simulator. Folks here should be able to guide you, I don't use it, sorry.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use avr simulator1 and when I step through the code, the yellow arrow goes down my C code and not the assembly behind it I guess. Ok though, I'll look more into it thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When debugging, under the "View" menu, select "Disassembler".

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is no question in my mind that an embedded programmer should have a good understanding of CPU architectures and instruction sets, especially those with which he is working. It's rare that I have to write in assembly language (but it does happen with regularity), but I need to be able to read and comprehend assembly language nearly every day. Usually that is assembly language generated by a compiler, but it can also be code found in app notes or other useful places.

The closer you are programming to the device (and with AVRs it's pretty close) the less you can afford to ignore their hardware and software architectures.

Mike

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
But Cliff's right. An expert embedded software engineer requires an appreciation of electronic hardware, a thorough understanding of how microprocessors work and how the instruction set interacts with the hardware, and an ability to program fluently in assembler (of whatever flavour) and appropriate high level languages.

And then where is the highly portability advantage claimed ?

Anyway you need to review all you code, architecture - compiler-specific functions, different memory-mapped specific functions, different peripherals specific functions, variables types etc.
George.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smkipus wrote:
now I understand that C is just a bunch of macros for ASM.
Which is not true. C code when compiled and linked produces machine code which is not assembler code. Even if from machine code, when disassembled, you can get assembler code.

MS/DOS macro assembler was a good example of "a bunch of macros for ASM" but not a C compiler nor any other language compiler.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
And then where is the highly portability advantage claimed ?

Portable in what circumstance, and advantage over what? If you are talking C over asm, then how much of an advantage depends on the circumstance. If it is from one AVR to another, the advantage might not be very much. Porting from an AVR to a PIC or an ARM, there is a tremendous advantage since the asm would not be portable at all.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
C code when compiled and linked produces machine code

Originally compilers did generate assembly language. Then the assembler would come in as a separate program and produce an object file. Then a linker would come in and produce a memory image. Then a loader would run and stuff it into memory. You could watch the sequence (yes, computers were a little slow) and capture the output of any one of the steps.

Things are combined, merged, and not so clearly delineated these days. Getting your assembly language from disassembling the final output would have been a pretty strange idea at one time.

typo. second hand brain.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

Last Edited: Wed. Sep 16, 2009 - 01:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And by portable, I don't think any of us mean: "Cut, paste, leave brain at doorstep."

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had an enlightening experience building a small 8051 based instrument. Having reached about 1500 lines of assembly I thought I had all the ticks down pat, macros for tedious small clips of code, reusable functions, nicely segregated files and lots of nice comments. I also had some extremely tenacious bugs and was at my wits end as to how to solve them. In desperation I decided to redo it all and so in 2 months I had it all working in Pascal. All the old bugs gone and only a few manageable new ones.

What did I learn?

Not so much that the high level language is better, rather that the rewrite went better because I had done all the planning and that with a clear map ahead of me I was faster and introduced less bugs.

Klave

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Klave,

What you say reminds me of another aphorism that I sometime like to add to the C vs ASM controversy (which this isn't but WTH) "Any sufficiently experienced ASM programmer who builds lots of large programs will eventually reinvent the C programming language." This ties into other ideas that C is a portable assembly language program and that C is the high level (okay mid-level) language that most emulates the underlying hardware. I didn't even approach reinventing C when I was doing ASM, so I guess we should insert 'smart' somewhere around 'sufficiently experienced'. Oh, and Pascal is cool too, but AFAIK it more closely emulates the way one might think about data processing (IMHO) rather than the way the machine works (IMHO anyway, since I'm no Pascal and we might want to reserve such comparisons for another thread.)

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Klave wrote:
I had an enlightening experience building a small 8051 based instrument. Having reached about 1500 lines of assembly I thought I had all the ticks down pat, macros for tedious small clips of code, reusable functions, nicely segregated files and lots of nice comments. I also had some extremely tenacious bugs and was at my wits end as to how to solve them. In desperation I decided to redo it all and so in 2 months I had it all working in Pascal. All the old bugs gone and only a few manageable new ones.

What did I learn?

Not so much that the high level language is better, rather that the rewrite went better because I had done all the planning and that with a clear map ahead of me I was faster and introduced less bugs.

Klave

"Plan to throw one away; you will, anyhow."

-Fred Brooks
"The Mythical Man-Month"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

C code when compiled and linked produces machine code which is not assembler code.

Can't speak for other compilers but as Chuck says some compilers work by first converting the C to Asm source code then passing it to an assembler - GCC for AVR works like this. If you invoke GCC with "-save-temps" you'll see the .s files that are passed to the assembler in binutils.

In fact, when using GCC the .lss is useful as is the mixed C/Asm view in the simulator/debugger but both of these reconstitute the Asm source from the binary using a disassembler.

Using either "make file.s" for a given file.c or the -save-temps thing will give you the actual source generated by the C compiler. I also like to use -fverbose-asm which adds far more comments to these .s files to explain what's going on.

An optimisation technique you can use is to write a function in a .c file, compile it to the .s Asm. Rename the .s to .S and then add it to the ASRC (and remove the original .c - now you can work on hand optimising this generated Asm code.

It's also possible to write Asm code from scratch and link it to the existing C (or replace it completely) with GCC as shown in:

http://www.nongnu.org/avr-libc/u...
http://www.nongnu.org/avr-libc/u...
http://www.nongnu.org/avr-libc/u...

and if you are a real masochist you can always look at:

http://www.nongnu.org/avr-libc/u...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

用c编写框架,asm则处理实时性强的地方,就如同uc/os一样

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
To my mind you cannot write C properly without understanding the underlying assembler that is being generated. For one thing, debugging optimised C is very tricky unless you use the mixed C+Asm view and doing that is a perfect way to gain familiarity with the Asm of the particular chip being used.

I have to agree with Cliff here. I primarily use C on the AVR, only resorting to assembly when I have good reason to do so (e.g. shorten a bottleneck in the code) and even then, it's only for a few functions at a time.

However, my general philosophy is to optimise for code maintainability and re-use first, programmer productivity next and performance last, subject to any timing constraints.

And old saying on optimisation:
- Beginners should not optimise
- Experts should not optimise... yet.

With the point being that performance issues can sometimes occur when they are least expected. Looking at the generated assembler is an excellent way to determine where some of these bottlenecks may be, and potential strategies to mitigate.

-- Damien

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

While C can be obfuscated, IF it is done properly it may be easier to understand and debug than assembly. On the other hand, knowing assembler can help when code compression is needed. There are a number of places in the code I work with where a comment such as
/* Going from C to assembler saves 23 bytes here */
is seen. I leave the original C code -- commented out -- in place to know what was intended.

Take a look at "Writing Solid Code" by Steve Maguire and "Code Complete" by Steve McConnell to see some nightmares C can produce, as well as how to fix/prevent them. You may also be interested in "Let's Build a Compiler" by Jack Crenshaw -- it's on the 'Net -- to get some idea of why a compiler generates the code it does.

HTH,
--Rich

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Can't speak for other compilers but as Chuck says some compilers work by first converting the C to Asm source code then passing it to an assembler - GCC for AVR works like this. If you invoke GCC with "-save-temps" you'll see the .s files that are passed to the assembler in binutils.
I didn't know this about GCC. But is doesn't convert GCC in a macro assembler. There is more than that.

I am not in favor of assembler. I have been a C programmer since 1990 working in MSDOS, Unix, Xenix, Linux, Windows and some microcontrollers (I am just an amateur in microcontrollers) and I think C is the best way to go.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
用c编写框架,asm则处理实时性强的地方,就如同uc/os一样

Now there's a man who knows how to pronounce "char" :wink:

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
But is doesn't convert GCC in a macro assembler

???

A macro assembler is simply an assembler that allows the use of macros. Virtually all assemblers these days are macro assemblers.

Perhaps you are saying the compiler doesn't convert the C to a series of macros? That I would agree with, for any C compiler.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

RiJoRi wrote:
While C can be obfuscated, IF it is done properly it may be easier to understand and debug than assembly.

While asm can be obfuscated, IF it is done properly it may be easier to understand and debug than C.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

But is doesn't convert GCC in a macro assembler. There is more than that.

Not sure I follow the point but if I write this in GCC:

#include  

int main(void) { 
	DDRB = 0xFF;
	while (1) {
		PORTB ^= 0xFF;
	}
}

Then what the C compiler does is convert it into this:

	.file	"test.c"
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__CCP__  = 0x34
__tmp_reg__ = 0
__zero_reg__ = 1
 ;  GNU C (WinAVR 20090313) version 4.3.2 (avr)
 ; 	compiled by GNU C version 3.4.5 (mingw-vista special r3), GMP version 4.2.3, MPFR version 2.4.0.
 ;  GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 ;  options passed:  -I. -imultilib avr5 -iprefix
 ;  c:\winavr-20090313\bin\../lib/gcc/avr/4.3.2/ -MMD test.d -MF
 ;  .dep/test.s.d -MP -MQ test.s -DF_CPU=8000000UL test.c -mmcu=atmega16
 ;  -auxbase-strip test.s -Os -Wall -Wstrict-prototypes -std=gnu99
 ;  -fverbose-asm -funsigned-char -funsigned-bitfields -fpack-struct
 ;  -fshort-enums
 ;  options enabled:  -falign-loops -fargument-alias -fauto-inc-dec
 ;  -fbranch-count-reg -fcaller-saves -fcommon -fcprop-registers
 ;  -fcrossjumping -fcse-follow-jumps -fdefer-pop -fearly-inlining
 ;  -feliminate-unused-debug-types -fexpensive-optimizations
 ;  -fforward-propagate -ffunction-cse -fgcse -fgcse-lm
 ;  -fguess-branch-probability -fident -fif-conversion -fif-conversion2
 ;  -finline-functions -finline-functions-called-once
 ;  -finline-small-functions -fipa-pure-const -fipa-reference -fivopts
 ;  -fkeep-static-consts -fleading-underscore -fmath-errno
 ;  -fmerge-constants -fmerge-debug-strings -fmove-loop-invariants
 ;  -fomit-frame-pointer -foptimize-register-move -foptimize-sibling-calls
 ;  -fpack-struct -fpeephole -fpeephole2 -freg-struct-return -fregmove
 ;  -freorder-functions -frerun-cse-after-loop -fsched-interblock
 ;  -fsched-spec -fsched-stalled-insns-dep -fsigned-zeros
 ;  -fsplit-ivs-in-unroller -fsplit-wide-types -fstrict-aliasing
 ;  -fstrict-overflow -fthread-jumps -ftoplevel-reorder -ftrapping-math
 ;  -ftree-ccp -ftree-copy-prop -ftree-copyrename -ftree-dce
 ;  -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-loop-im
 ;  -ftree-loop-ivcanon -ftree-loop-optimize -ftree-parallelize-loops=
 ;  -ftree-reassoc -ftree-salias -ftree-scev-cprop -ftree-sink -ftree-sra
 ;  -ftree-store-ccp -ftree-ter -ftree-vect-loop-version -ftree-vrp
 ;  -funit-at-a-time -fverbose-asm -fzero-initialized-in-bss

 ;  Compiler executable checksum: abe89850c430a90419070abaa31bf632

	.text
.global	main
	.type	main, @function
main:
/* prologue: function */
/* frame size = 0 */
	ldi r24,lo8(-1)	 ;  tmp45,
	out 55-32,r24	 ; ,, tmp45
.L2:
	in r24,56-32	 ;  D.1218,,
	com r24	 ;  D.1218
	out 56-32,r24	 ; ,, D.1218
	rjmp .L2	 ; 
	.size	main, .-main

which is then passed to avr-as to be assembled.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I MUST remember that.
I MUST remember that.
I MUST remember that.

I best in this thread.

I remember a remark that I used in an assembly code. It was too hard to explain all of my thought so I wrote:

;It plays, don't ask, don't touch, don't think.

About 2 year layter I crossed around the same program and I show the details in order to remember the concept. It was the only time I really didn't spend my time to remember my code. I am sure it was my best note.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
IF it is done properly it may be easier to understand and debug than C.

Bull.

C:
a = b + c;

Write the equivalent (using integers) in asm and let's see how easy it is to understand.

Then do it with different size integers.

Then do it with floats.

Then with b as a float and a and c as integers.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Koshchi wrote:
Quote:
IF it is done properly it may be easier to understand and debug than C.

Bull.

C:
a = b + c;

Write the equivalent (using integers) in asm and let's see how easy it is to understand.

;a = b + c
[... some assembly code here...]

Koshchi wrote:
Then do it with different size integers.

;a = b + c
[... some assembly code here...]

Koshchi wrote:
Then do it with floats.

;a = b + c
[... some assembly code here...]

Koshchi wrote:
Then with b as a float and a and c as integers.

;a = b + c
[... some assembly code here...]

(Of course, the comment should reflect the intention rather than method; but there's not enough information in Steve's example to do that properly).

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't see one single line of assembly code in your example. Your use of comments written in C to explain the actual code only proves my point. And if the code has a bug in it, changing the comment won't fix the bug.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
[... some assembly code here...]

Great coding technique. Instantly I know every programming language ever devised. And they're all very easy, it turns out, so what's all the fuss about?

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

zbaird wrote:
Quote:
But is doesn't convert GCC in a macro assembler

???

A macro assembler is simply an assembler that allows the use of macros. Virtually all assemblers these days are macro assemblers.

Perhaps you are saying the compiler doesn't convert the C to a series of macros? That I would agree with, for any C compiler.

I am Sorry, I made a typo. What I wanted to write was: But it doesn't convert GCC in a macro assembler.

clawson wrote:

Not sure I follow the point but if I write this in GCC:

#include  

int main(void) { 
	DDRB = 0xFF;
	while (1) {
		PORTB ^= 0xFF;
	}
}

Then what the C compiler does is convert it into this:

	.file	"test.c"
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__CCP__  = 0x34
__tmp_reg__ = 0
__zero_reg__ = 1
 ;  GNU C (WinAVR 20090313) version 4.3.2 (avr)
 ; 	compiled by GNU C version 3.4.5 (mingw-vista special r3), GMP version 4.2.3, MPFR version 2.4.0.
 ;  GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 ;  options passed:  -I. -imultilib avr5 -iprefix
 ;  c:\winavr-20090313\bin\../lib/gcc/avr/4.3.2/ -MMD test.d -MF
 ;  .dep/test.s.d -MP -MQ test.s -DF_CPU=8000000UL test.c -mmcu=atmega16
 ;  -auxbase-strip test.s -Os -Wall -Wstrict-prototypes -std=gnu99
 ;  -fverbose-asm -funsigned-char -funsigned-bitfields -fpack-struct
 ;  -fshort-enums
 ;  options enabled:  -falign-loops -fargument-alias -fauto-inc-dec
 ;  -fbranch-count-reg -fcaller-saves -fcommon -fcprop-registers
 ;  -fcrossjumping -fcse-follow-jumps -fdefer-pop -fearly-inlining
 ;  -feliminate-unused-debug-types -fexpensive-optimizations
 ;  -fforward-propagate -ffunction-cse -fgcse -fgcse-lm
 ;  -fguess-branch-probability -fident -fif-conversion -fif-conversion2
 ;  -finline-functions -finline-functions-called-once
 ;  -finline-small-functions -fipa-pure-const -fipa-reference -fivopts
 ;  -fkeep-static-consts -fleading-underscore -fmath-errno
 ;  -fmerge-constants -fmerge-debug-strings -fmove-loop-invariants
 ;  -fomit-frame-pointer -foptimize-register-move -foptimize-sibling-calls
 ;  -fpack-struct -fpeephole -fpeephole2 -freg-struct-return -fregmove
 ;  -freorder-functions -frerun-cse-after-loop -fsched-interblock
 ;  -fsched-spec -fsched-stalled-insns-dep -fsigned-zeros
 ;  -fsplit-ivs-in-unroller -fsplit-wide-types -fstrict-aliasing
 ;  -fstrict-overflow -fthread-jumps -ftoplevel-reorder -ftrapping-math
 ;  -ftree-ccp -ftree-copy-prop -ftree-copyrename -ftree-dce
 ;  -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-loop-im
 ;  -ftree-loop-ivcanon -ftree-loop-optimize -ftree-parallelize-loops=
 ;  -ftree-reassoc -ftree-salias -ftree-scev-cprop -ftree-sink -ftree-sra
 ;  -ftree-store-ccp -ftree-ter -ftree-vect-loop-version -ftree-vrp
 ;  -funit-at-a-time -fverbose-asm -fzero-initialized-in-bss

 ;  Compiler executable checksum: abe89850c430a90419070abaa31bf632

	.text
.global	main
	.type	main, @function
main:
/* prologue: function */
/* frame size = 0 */
	ldi r24,lo8(-1)	 ;  tmp45,
	out 55-32,r24	 ; ,, tmp45
.L2:
	in r24,56-32	 ;  D.1218,,
	com r24	 ;  D.1218
	out 56-32,r24	 ; ,, D.1218
	rjmp .L2	 ; 
	.size	main, .-main

which is then passed to avr-as to be assembled.

Cliff

That process is called Compilation. No macro expansion occurred. I am not talking about C macros (#define, #if defined(...), etc) which is a different thing.

Remember that I am discussing about the phrase "C is just a bunch of macros for ASM" which I consider as not true.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
But is doesn't convert GCC in a macro assembler
Quote:
I am Sorry, I made a typo. What I wanted to write was: But it doesn't convert GCC in a macro assembler.
Oh.

Quote:
That process is called Compilation. No macro expansion occurred.

Remember that I am discussing about the phrase "C is just a bunch of macros for ASM" which I consider as not true.


Compilation is typically a two step process, one of converting to assembly language, and one of converting to machine language.

I think Cliff and I (if I may be so bold as to speak for him) agree with you that C is not just a bunch of macros. But C does (or can) get converted into assembly language, which does (or can) get processed by a macro assembler. It's not done using a bunch of one-to-one macros, however.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

"C is just a bunch of macros for ASM" which I consider as not true.

It may not be directly true but the structure you add to Asm by using Macros (while loops, for loops, case statements, etc. etc.) are available as standard constructs in C - that's the point. C just makes "Asm style programming" a bit easier, more maintainable, more readable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
the structure you add to Asm by using Macros (while loops, for loops, case statements, etc. etc.)

But I don't see how you can call those "Macros". They are keywords of the language. The compiler writer might choose to implement them as Macros, but it is certainly not dictated by the language.

Quote:
C just makes "Asm style programming" a bit easier, more maintainable, more readable.

I disagree with this as well. When I program in assembly I use considerably different techniques than when I program in asm.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

C compilers are very sophisticated in terms of optimizing code, in-line functions, very clever management of variables and pointers cached in registers, and so on.

Many years ago we had an image processing algorithm that was complex and time consuming. After doing all we could at the formula optimizing, I challenged our veteran assembly language programmers to code the iterative part of this, a lot of code, and beat the good compiler we were using (on DEC Alphas). The compiler won in execution speed, due to very clever management of register usage among many subroutine calls.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will say it an other way. To realy know C and ASM you need to learn how a compiler is structured. I have used the LCC compiler (it’s free) and have the book.

If you know how a compiler works you avoid to ‘kill’ the AVR in some fancy C code.

And when you code in ASM you know how to structure a program/project.
But it does NOT mean that you reinvent C as Smiley stated. The main problem with C on a small micro is that you have to use a fairly fixed model for pointers memory etc. Numbers has to have a fixed length normally 8, 16 and 32 bit.
And there is no direct way to use the flag’s and I have never seen a non trivial ASM program not using those.

Jens

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

"C is just a bunch of macros for ASM" which I consider as not true.

It may not be directly true but the structure you add to Asm by using Macros (while loops, for loops, case statements, etc. etc.) are available as standard constructs in C - that's the point. C just makes "Asm style programming" a bit easier, more maintainable, more readable.
I don't think this can be "true" or "not true" - IMHO it's a mindset.

It's certainly possible to write FORTRAN in any language, so you can have an asm mindset in C, trying to understand the effect of most of the statements and, consciously or subconsciously, optimising them on the go.

While this is certainly possible, I don't think it's right. Once using a high(er) level language, think high level; once using a language which has its relationship with structured languages, think structures - and try not to care about the resources (in a reasonable way, of course).

Not that my opinion matters much, but it felt good to perpetuate it ... :-)

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Koshchi wrote:
I don't see one single line of assembly code in your example. Your use of comments written in C to explain the actual code only proves my point. And if the code has a bug in it, changing the comment won't fix the bug.
I would not use "comments written in C" in most of the cases, as I explained above. Comments are to explain purpose. a = b + c is none more clear than

ld acc, c + 0
add acc, b + 0
st a + 0, acc
ld acc, c + 1
adc acc, b + 1
st a + 1, acc

or

FLOAT_ADD(a, b, c)

without context - and there's more in "context" than just comments, whatever their style is.

The "mathematical"-like notation makes the program none cleaner to understand.

And, Steve, of course it proves your point - with a bit of imagination, absolutely anything can be seen as a proof of your point. I know you can provide better arguments than just that.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Has anyone read George Bush's memoirs yet?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:
...and try not to care about the resources (in a reasonable way, of course).
That is the reasoning MS people did and now Windows Vista needs 2 GB to do what XP did with 512MB or less.

I started programming back in 1970's when I was still at the school. I bought a casio FX-3500P (P from programmable). There were only 38 steps to write the entire program. I think that was a good beginning for me because I learned that every single bit counted.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So would you say that if you have a good understanding of ASM, then you can write your C code in such a way that it is more efficient? I read an article in the AVR forum
Efficient C Code for Eight-Bit MCUs
http://www.embedded.com/98/9811/9811fe3.htm
and it never really said you should have an "asm mindset" when writing C but rather it emphasized using proper types for everything (ie not using an int in a for loop to count from 0 to 10 but rather to use unsigned chars)

I almost am believing that I'm trying to learn this asm thing backwards, I suspect most of savvy gray-beards here learned asm before C.

clawson wrote:
In fact, when using GCC the .lss is useful as is the mixed C/Asm view in the simulator/debugger but both of these reconstitute the Asm source from the binary using a disassembler.

Using either "make file.s" for a given file.c or the -save-temps thing will give you the actual source generated by the C compiler. I also like to use -fverbose-asm which adds far more comments to these .s files to explain what's going on.

An optimisation technique you can use is to write a function in a .c file, compile it to the .s Asm. Rename the .s to .S and then add it to the ASRC (and remove the original .c - now you can work on hand optimising this generated Asm code.

This was very helpful, not that the rest wasn't. I'm still working on baby optimising my C code by not including libraries if I don't need to such as writing my own ITOA functions instead of including the whole .

So after reading the 80+ posts again, It seems like the lesson I should take away is to learn asm but keep coding in C since that is working for me. I think for the kind of tinkering I do, asm may speed up my code when I need to do port outputs or IO interrupts but when I need to make serial com protocol or something more complicated, C should suffice even though I'll sacrifice some speed.

Finally, the asm tutorial projects I've done so far don't seem to resemble the asm generated by the disassembler. The disassembler in the AVR gcc simulator does still use commands like out, ldi, etc but it doesn't have the same format, it gives that lefthand column with the registers listed out before it even gets to the main.c file. I hope this makes sense. Anyways yah, all lots of good stuff.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
before it even gets to the main.c file.
Remember that C executes some initialization code prior to getting to yours. It has to move initialized variables from flash to SRAM, zero out uninitialized variables, and suchnot.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All knowlege is useful, so having at least some knowlege of assembler may at sometimes come in handy. Assembler is cryptic at best, but don't try to emulate writing assembler the same way the compiler spits it out - otherwise you'll cause yourself some grief in the future when you need to maintain the code. Many years ago I always used to write highly optimised assembler but then you realise that you spend a lot of time optimising code and debugging it. When you had devices with only 4k of eprom, you sometimes needed to take drastic actions to squeeze it all in - this takes time and may introduce defects. Nowadays you'd weigh up going to a larger part at probably 50c extra and saving hours of your time, or being financially compelled to squeeze it into the smallest , cheapest part.

For an old timer like me, it was a bitter pill to swallow that a compiler could do better than me. Then you relaise the compiler can pull tricks that you wouldn't normally do or want to do. Ultimately, it comes down to writing defect free code - you could write the fastest, smallest code, but if it doesn't work then it is useless.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My experience was that I began as an assembly language programmer for big team projects on mini-computers. For many years.

When I tried C, having previously done FORTRAN and Pascal, I just couldn't get the knack of C's pointers and pointers to functions.

Then one day, I realized that K&R's C is just a portable assembler. It doesn't protect you from dumb mistakes any more than an assembler does. It does not restrict you as do actual high level languages.

I think C is the best of both worlds and have written most of my code over the years in C.

Rapid app development for non-deliverable stuff on PCs is written in Visual Basic. Microsoft C++ and C# is just too bloated for me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Koshchi wrote:
I disagree with this as well. When I program in assembly I use considerably different techniques than when I program in asm.
Now I'm really confused.

Are we going to start having 'assembly versus asm' wars?

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
Koshchi wrote:
I disagree with this as well. When I program in assembly I use considerably different techniques than when I program in asm.
Now I'm really confused.

Are we going to start having 'assembly versus asm' wars?

Smiley


Assembly sucks. Asm rulez!

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Many years ago I always used to write highly optimised assembler but then you realise that you spend a lot of time optimising code and debugging it.

Yes, that's a common error when writing entire application in asm. I've seen several successful asm programmers who apparently deliberately suppressed this (often subconscious) push.

Kartman wrote:
For an old timer like me, it was a bitter pill to swallow that a compiler could do better than me.

Rather than feeling bad, the old timer should realise, that the compiler does inevitably better than him in those places where computers (or machines generaly) do better than humans. They are tireless and don't forget, but they are sort of dumb. In programming, this means that machines have an edge in handling lengthy algorithms (there's a good example in this thread where an asm guy was beaten by machine in implementing a highly complex algorithm, I can't find it at the moment), huge and complex datasets and unimportant, routinely repeated and boring tasks (like handling menues and human input). Humans have edge in relatively short routines with clear set of relatively few inputs and outputs, an in very non-typical situations. Now decide, which of these matches better your typical programming task.

Kartman wrote:
Ultimately, it comes down to writing defect free code - you could write the fastest, smallest code, but if it doesn't work then it is useless.

Yes, but this is independent on language. It is the *match* of the language (better: tools) and the task, which really matters.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Koshchi wrote:
Quote:
用c编写框架,asm则处理实时性强的地方,就如同uc/os一样

Now there's a man who knows how to pronounce "char" :wink:

sorry,i am chinese,what your reply like a joy, :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
Rapid app development for non-deliverable stuff on PCs is written in Visual Basic. Microsoft C++ and C# is just too bloated for me.

VB6, I presume? VB .NET shares a common run-time language with C# with all it's associated, ummm... bloat.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

So would you say that if you have a good understanding of ASM, then you can write your C code in such a way that it is more efficient?

That would be my summary: "Think in ASM, write in C."

The C compilers will do a decent job of code generation--if you give them half a chance. Just as in ASM, when you know what is in the registers (variable contents) you can take short cuts. If you multiply an 8-bit unsigned value by a signed 32-bit quantity, the rules of C and extension of arguments etc. could generate many many instructions (words, cycles). But when you >>know<< at that point that the 32-bit value contains a small unsigned number, a simple cast to help the compiler will generate a satisfactory instruction sequence.

I find it fairly straightforward to page through the generated code listing from time to time during development (which has the C source lines interspersed). It quickly becomes apparent which sections could use some attention--generally there are a few ASM lines for each C line. When one (or a few) C lines generate screenfuls of machine code then that might warrant further investigation.

Quote:
I've expressed my heretical views on this before--these are >>micro<< controllers. There >>are<< only a few number of items. If you want to craft a tight, fast, packed app of the Mega88 (give-or-take) class, then have register based scratchpads and use the crap out of them. Nearly all global data. Do whatever can be reasonably/logically done in main() in main(). Don't use functions just for the sake of structure without a reason. [E.g., my chip-init sequence is straight-line code, unless the app may require re-init of subsystems at some point. This is fairly rare.] Few parameters. Little local data except when it really >>is<< local--loop counters and the like.

https://www.avrfreaks.net/index.p...

Quote:

I'm still working on baby optimising my C code by not including libraries if I don't need to such as writing my own ITOA functions instead of including the whole .

If you need the function of library routines, they are probably pretty well written. Now, in this "itoa()" class there is a lot of discussion as it is often needed to format/display a value. [There is a VERY extensive thread on this that has a lot of C vs. ASM in it--search it out. https://www.avrfreaks.net/index.p... Also see https://www.avrfreaks.net/index.p... ] I don't see what iostream has to do with it.

What I find is that I usually want right justification and leading zero suppression and maybe signed and maybe implied decimal point insertion. So I have rolled my own. But the library's itoa() itself is probably well done.

Quote:

but when I need to make serial com protocol or something more complicated, C should suffice even though I'll sacrifice some speed.

Except in the goriest of apps (VGA video generation; Jesper's miniDDS) I can't see how that can be justified--why would using C sacrifice any speed? A wizard like wek writing the whole app tightly in ASM can beat me no matter what language I use. But a section like a comms protocol parsing? If the ASM program uses gloabal registers to streamline things, I can do the same in C. Etc. etc.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brilliant find, jayjay!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I actually found it while I was looking for the video SmileyMicros mentioned about Ken and Dennis fighting in a cafeteria over the pronunciation of 'char' :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Its stuck in my head

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I was looking for the video SmileyMicros mentioned

My guess is that that one is only to be found in the dark recesses of certain semi-demented minds in Knoxville, Tennessee. :?

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

damien_d wrote:
stevech wrote:
Rapid app development for non-deliverable stuff on PCs is written in Visual Basic. Microsoft C++ and C# is just too bloated for me.

VB6, I presume? VB .NET shares a common run-time language with C# with all it's associated, ummm... bloat.

OT: (lol at >>that<<)

I decided that I had to get into the new millennium, and am in the middle of doing my first C# app after years of VB6.

C# is >>different<< than VB6, but I don't know yet about the "bloated" part.

As an old guy that hasn't grown up with object-oriented programming, having it forced on me is a bit painful.

I was expecting to be able to "write C in C#" but you can't quite do that.

I'm still a bit confused about the run-time requirements. To this point I've tested making some .EXEs and then carrying only the .EXE to a W98 machine that knows nothing of .NET and they run fine. So no big installs needed? Dunno; other references say yes.

Now, the provided "members" could be called bloated, perhaps. It seems like every possible method has already been implemented for you. So what might take a few hundred lines in VB6 tales a few dozen in C#. As a newbie the struggle is finding the right few lines to do it all for you.

I'd call the screen-drawing process the same, and give an edge to .NET.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
a W98 machine that knows nothing of .NET

No Windows Update done?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

No Windows Update done?

Hmmm--perhaps. But needing certain DLLs in the Windows directory is probably cool--is that what you are getting at?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Look under Add/Remove Programs. Do you see anything like ".Net Framework" or similar?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

zbaird wrote:
Quote:
I was looking for the video SmileyMicros mentioned

My guess is that that one is only to be found in the dark recesses of certain semi-demented minds in Knoxville, Tennessee. :?
'minds'? We are wondering what you are implying about us?

And that video was posted on YouTube on Feburary 18th, 1975, it should be very easy to find using the posting date.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
And that video was posted on YouTube on Feburary 18th, 1975, it should be very easy to find using the posting date.

Smiley


How old is YouTube, anyway?

I remember now! I toggled to the YouTube website in record time back in 1974, using my SWTP MC6800 based computer - the 12" x 12" x 6" box with a front panel full of toggle switches. I think that computer kit was published in Popular Electronics in about 1973 or 1974. Man, was I happy when the TRS-80 Model 1 came along!!! 8)

Now, weren't those the good-ole days? :lol:

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Someone, (or two), have obviously been playing with their AVR based time machines again...

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Someone, (or two), have obviously been playing with their AVR based time machines again...

And I thought they were playing with their AVR based leg pulling machines.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The original Altair coverage was in the January 1975 Popular Electronics. The Southwest Tech 6800 didn't come out until November of that year.

http://en.wikipedia.org/wiki/Fil...

http://en.wikipedia.org/wiki/Fil...

I think most people accessed YouTube with a PDP8 back then. :) But playing those videos on a KSR-33 teletype was a real pain.

/Dave/

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FWIW I used to have an IMSAI 8080. My first computer. Cost the parents a fortune back then, wanted it after I saw the movie "WARGAMES" with Matt Broderick.

I think I might still have it.

Jim[img]FWIW I used to have an IMSAI 8080. My first computer. Cost the parents a fortune back then, wanted it after I saw the movie "WARGAMES" with Matt Broderick.

I think I might still have it.

I found the pic off the internet as I really was in no hurry to find/photo the one I might still have

Jim

Edit:

Here is what a working unit goes for NOW:
http://cgi.ebay.com/Vintage-IMSAI-8080-S100-Low-S-003878-NEC-8080A-Works_W0QQitemZ190307992840QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item2c4f3d8508&_trksid=p3286.m20.l1116

Attachment(s): 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

those early PCs emulated the PDP-8 with the keys and lights.
I had a Swtpc SS-50 bus computer with 8" floppy and Flex OS. State of the art!

At work, we had moved to PDP-11s and DEC-Tape, then Century disk drives as big as a dish washer for 300MB

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My commodore 64 still works, games and everything. The Velcro glue on the anti-blur screen is coming off though. I've never even heard of one of those blue things though, and 3000 bucks??? Holy smokes!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But the important question

Quote:
Has anyone read George Bush's memoirs yet?
has not been answered yet!!

I caught a bit on one of the talk back radio programs a few days ago and a little last night on the David Letterman show.

I'm sure it will make great reading...or video watching. I'll wait for the video I think.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is it written in C, or assembly language?

(on second thought, since it's George, it's probably written in C-)

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

More likely in D (Disconnected language) :? Lets' get this thread back on some serious stuff!!

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
But the important question
Quote:
Has anyone read George Bush's memoirs yet?
has not been answered yet!!

I caught a bit on one of the talk back radio programs a few days ago and a little last night on the David Letterman show.

I'm sure it will make great reading...or video watching. I'll wait for the video I think.

In the future on a visit to Hell I saw George Bush in a pit of boiling sewerage his mouth an nose barely out and he was giggling. I said, 'Man, what you got to be happy about this looks like the worse punishment they got down here." He gurgled, "Nah, that would be Dick Cheney's, I'm standing on his shoulders."

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are there AVR Studios assembler books to learn this thing with? Got code complete 2 right now, it's an alright read. Think it's better to just learn by doing and trial and error/internet tutorials or is there like a atmel assembler for dummies thing available? I'm trying to right USART code in assembler and it's frustrating to say the least. Loops remind me of programming on my TI 83 calculator... Oh, and I do know that there's all kinds of machine language books posted in the guides section, I was hoping for something specifically for Atmega 8 Bits. Found a bunch of tutorials on the internet obviously but its still a daunting task. It'd be nice if there were a book like do this,this, this, this, now you are a pro at avr assembler. Anyways, thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
now you are a pro at avr assembler.
AVR assembler is not much different than other assemblers for other micros, so the thing to keep in mind is NOT just to learn "AVR assembler" but to learn assembler in general.

The same way if you learned C or Pascal or BASIC. Once you get the basics then you can change assembler, compiler, micros with some ease. Will just need to learn the quirks of what you use but the mind set remains the same.

And the ATmega 8 is not much different than other Megas or Tinys, so don't get a tunnel vision.

Studio is just an IDE. Once you know what you want to do and what you should be able to do you can switch to MPLAB (Microchip) or PEMICRO's IDE (Motorola\Freescale) or one of the IAR IDE for AVR or MSP430.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The SWTPC 6800 kit did not have toggle switches, except for the power switch.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So in ASM, I'm now trying to get used to using r0-r31, the multipurpose registers. When I write C code and I go and make a

int IArray [20];
IArray[0]=2;
IArray[1]=3;....

Where does my IArray get stored? Does it load up r0-r31? If it doesn't (which I suspect it doesn't), what registers does it put these numbers into? Also, I've seen a lot of places saying not to use r0 through r15. Can I use them anyways?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smkipus wrote:
So in ASM, I'm now trying to get used to using r0-r31, the multipurpose registers. When I write C code and I go and make a

int IArray [20];
IArray[0]=2;
IArray[1]=3;....

Where does my IArray get stored? Does it load up r0-r31? If it doesn't (which I suspect it doesn't), what registers does it put these numbers into?


It puts them into RAM. The easiest way to see what happens in this case is to look at the assembly listing from the compiler.

Quote:
Also, I've seen a lot of places saying not to use r0 through r15. Can I use them anyways?

Yes you can. But you need to impose some kind of discipline and order on your register usage or you will quickly tie yourself in knots. You can invent your own rules for register allocation, or you can borrow an existing set of rules e.g. the rules used by a particular compiler. In that case you can assume that they have thought through allocation issues that might not have occurred to you.

The bigger your program, the more important it is to be disciplined with your registers.

Mike

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I'm now trying to get used to using r0-r31, the multipurpose registers.
Only r16-r25 are real multipurpose strictly speaking.

ie
r0 and r1 are used by the MUL type instructions so use with care.
r0-r15 cannot do immediate type operations like LDI.
r26-r31 are index registers (X,Y,Z) again use with care.

r24 and r25 are good registers to use for temps as they can also do some 16 bit ops like ADIW.

So "general purpose or multi purpose" is not 100% true. :)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks John and Mike. While I have you guys, another question.

So if I wanted to set up like 8 bytes to use as a uchar array and then do math to them, would the flow go like this?

Set value in r24 or r25

move r24 into the sram locations (where my array would live), maybe 0x0100, 0x200, etc
Then if I want to add or subtract or do math I would move the sram value into r24, do a subi, then put the new value in r24 back into the sram?

I'm reading a tutorial right now, kinda information overload but this is the way I think I am supposed to do this, am I even close?

Ok, last random question, sorry. What is the Interrupt Vector that I'd use if I wanted my mcu to do something when a variable turns to a specific value? I want to set a uchar to 1 when the uart finishes receiving a data packet. Then when that 1 turns into a 1, I'd want the device to know and perhaps do an action depending on the states of other flags. Can I set up an ISR that will trigger when my unsigned char Flag == 1? Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Can I set up an ISR that will trigger when my unsigned char Flag == 1?
Can you do that in C?

ISR are hardware linked, so they can only be triggered (usually) upon a hardware event like in C.

I would get away from thinking about unsigned char, char, arrays etc. they are EVIL C concepts. :lol:

You can use a register as a flag (faster) or a memory location.(slower as it needs to be loaded into a register, do some tests and then put back).

Everything in ram are JUST bytes (ie 8 flip flops each), whether array, uint8_t or whatever.

You assign a memory location, or several of them, space in ram with a label. A sample of a project ram allocation

;====================
.DSEG
;====================

ramstart:

EEP_ADDR:			.byte	2	;Pointer to data in eeprom internal or external
scroll_time:		.byte	1	;Gets copied to scroll_delay every scan
scroll_delay:		.byte	1	;Number of scan delay		
msg0:				.byte	PKIO_DATA_SIZE+1 ;Message 0 in ram.1 byte larger for CR
msg0_index:			.byte	2	;Pointer to next char in msg 0 buffer
dwell_timer:		.byte	1	;Beginning or End of messgae dwell timer
op2_timer:			.byte	1	;Timer value for OP2
op2_timer_buf:		.byte	1	;Buffer for timer value for OP2
op1_timer:			.byte	1	;Timer value for OP1
op1_timer_buf:		.byte	1	;Buffer for timer value for OP1
DIS_BUF:			.byte	26 	;Display buffer+1 for scroll char
msg_bfr:			.byte	26	;Current 25 + scroll chars being displayed
spi_out_bfr:		.byte	21	;10 lots of 2 bytes (+1) sorted to send out
cursor:				.byte	2	;Cursor position
pkt_type:			.byte	1	;Type of communication packet
;

MY_ADR:				.BYTE	1
	
CR_control_ptr:		.byte	2	;PKIO_DATA pointer for CR type packets
CRPK_N_BYT:			.BYTE	2	;Number of bytes in CR packet (16 bit)
char_cntr_save:		.BYTE	2 	;Save number of chars in current msg
n_slave_modules:	.byte	1

hundreds_seconds:	.byte	1
tens_seconds:		.byte	1

Are the memory locations signed, unsigned, char, uint16_t?? Who cares they are memory locations where stuff is kept.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

So if I wanted to set up like 8 bytes to use as a uchar array and then do math to them, would the flow go like this?

Set value in r24 or r25

move r24 into the sram locations (where my array would live), maybe 0x0100, 0x200, etc
Then if I want to add or subtract or do math I would move the sram value into r24, do a subi, then put the new value in r24 back into the sram?


R25/R24 are a bad choice of register if you are planning to work on an array of bytes in SRAM. The AVR has three regiter pairs R27:R26=X, R29:R28=Y, R31:R30=Z which are intended or this kind of thing. They are "index registers" because they can be used to index an array of data. If you have your array of bytes at 0x12C then use:

  ldi R26,low(0x12C) ; load X with addr
  ldi R27,high(0x12C)

then to load R24 with array element [3] use:

  ld R24, X+3

or starting at the beginning to process 8 entries:

  ldi R16,8:
process_loop:
  ld R24, X+
; use R24
  dec R16
  brne process_loop

BTW rather than hard code a location like 0x12C, use labels:

.dseg
myarray: .byte 8
.cseg
  ldi R28, low(myarray)
  ldi R29, high(myarray)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@js: do you have any book recommendations for "Assembler in General"?
I don't know that I've ever seen such a thing (though a general purpose "computer architecture" book might come close.) (The net effect is that it's better to learn more than one assembler "near" the same time. My college class did IBM360 and PDP11. By the time that was added to PDP10 that I already knew, and the 8080/z80, 6502, 6800 stuff that was in the hobby magazines, I was in pretty good shape to pick up any assembler and go to work...) (yeah, dating myself, eh?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't have any books in mind but Chuck Baird has written one about the AVR assembler. http://www.zbaird.com/ and he has changed a lot since the picture on the book was taken... :wink:

There is also some stuff on http://www.avrbeginners.net/

I learned ASM though the years (too many of them) starting with the 6800 (original course), 2650, 6502, 8085, z80, nsc800, pic, avr....oh no!! Too many of them. (NOT dating myself, Already married :lol: )

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The early days were swell; probably some 60% of the microprocessor vendors were claiming to have a PDP11-like instruction set, and figuring out where they did, and where they were lying, was particularly educational. And then you'd get the occasional not-at-all-like-a-pdp11 cpu (CDP1802?) and that would teach your something different.

I notice TI/Stellarius is documenting their peripherals in the form of a substantially complete C library (open source), which they are putting in ROM on the new part so that it will be always there and almost free. An interesting strategy...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
The early days were swell; probably some 60% of the microprocessor vendors were claiming to have a PDP11-like instruction set, and figuring out where they did, and where they were lying, was particularly educational. And then you'd get the occasional not-at-all-like-a-pdp11 cpu (CDP1802?) and that would teach your something different....
As someone who studied and worked with some of those CPUs as they appeared, I don't recall *any* chip vendor claiming a PDP11-like instruction, other than DEC. I suspect no one wanted to attract the lawyers from that large, and at the time, vigorous company.

The COSMAC 1802 actually shared some qualities of the PDP-11 but clearly drew inspiration from some other, alien source. I got the impression most people couldn't figure out what source, exactly. Once you grokked its pointer registers, however, you had no trouble picking up C. (Whew -- back on topic.)

- John

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jfiresto wrote:
The COSMAC 1802 actually shared some qualities of the PDP-11 but clearly drew inspiration from some other, alien source.

Are you sure with the "alien"? I doubt it, given the SEX instruction... :-P

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I remember a Doctor Who episode in which the new Doctor revealed he was from an alien planet.

This prompted his future sidekick to ask: "If you're an alien, how come you sound like you're from the North?"

His reply: "Lots of planets have Norths."

- John

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Old geezer quiz:

The often touted assembly language instruction HCF was what?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Halt and Catch Fire? (SEX op code is still my favourite.)

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jfiresto wrote:
I remember a Doctor Who episode in which the new Doctor revealed he was from an alien planet.

This prompted his future sidekick to ask: "If you're an alien, how come you sound like you're from the North?"

His reply: "Lots of planets have Norths."

The Doctor said "Lots of planets have a north."
Emphasis added.
Very few planets have more than one.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:
jfiresto wrote:

His reply: "Lots of planets have Norths."
The Doctor said "Lots of planets have a north."
Emphasis added.
Very few planets have more than one.
You are quite right.

- John

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

re the HCF instruction..

theusch wrote:
Halt and Catch Fire? (SEX op code is still my favourite.)

Lee


That's it!
Snort. Cough. Cough.

One of the first computers I programmed was an AN-UYK-1 which had 4K words (12 bit words) of core memory. If you did a jump . the core would overheat. HCF.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Chuck Peddle was on the team at Moto that did the 6800. It had room for 6800 transistors. There was a big argument... should we have 2 8 bit accumulators and 1 16 bit index register that could access all of memory, or 2 8 bit index registers? The 6800 has 1 16 bit index register... Chuck got miffed and quit and started MOS Technology and invented the 6502 with 2 8 bit index registers. Jobs and Wozniak put it in the Apple 1 and now they are all retired. I recall that the 6800 was designed to be 'an 8 bit pdp11' because it had memory mapped io like the pdp11, and jsr and rts instructions, and similar addressing modes... immediate, indexed, direct, extended. QED.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I kind of remember HCF from my days writing 6809 code.
I really liked that micro - compared to the 8080 of the day it was a cadillac

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, I have a question.... I always did assembler on a bigendian moto cpu, so 2 byte and 4 byte variables were always in 'human readable' order.. 0x1234 in the AB register pair in the 6800 had 0x12 in A and 0x34 in B. When you dumped 0x12345678 from a long ram var to the screen it came out in that order. Hi byte first. I did a little 8080 and Z80 and I notice that HL holds an address in bigendian order, supposedly for the benefit of the carbon based programmers, but the word pointed to by HL gets stored lo byte first in ram. Is the a convention for AVRs? if I want to add a string of 16 bit words, I allocate a register pair as an accumulator, and start summing low bytes and then ad with carry all the hi bytes. But is the lo numbered register the hi byte or lo byte of the accumulator? Or does it matter and just scatter the accumulator bytes around willy nilly as available??

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think it is more what you are comfortable with. One exception might be if this is an address, then you would want to put them in a register pair in the correct order so that they would work properly when using movw to put them into an index register.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
When you dumped 0x12345678 from a long ram var to the screen it came out in that order. Hi byte first.

a raw memory dump of bytes would do that. But decent debuggers and like tools have options to dump 16, 32, 64 bit signed an unsigned values while using the native byte order of the underlying CPU. Alas, the ARM TDMIs can do either-Endian at run-time and so do their compilers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
OK, I have a question.... I always did assembler on a bigendian moto cpu, so 2 byte and 4 byte variables were always in 'human readable' order..
Such statements show a quite common failure of imagination.
Bigendian is human readable if the human reads from
the left and the byte indexes start on the left.
When writing a dumper for bigendian,
I start the indexes on the right.
As noted by another, this does not help in the ambidextrous case.
Quote:
0x1234 in the AB register pair in the 6800 had 0x12 in A and 0x34 in B. When you dumped 0x12345678 from a long ram var to the screen it came out in that order. Hi byte first.
That is a function of the dumper.
Quote:
I did a little 8080 and Z80 and I notice that HL holds an address in bigendian order, supposedly for the benefit of the carbon based programmers, but the word pointed to by HL gets stored lo byte first in ram.
I think that is a function of the compiler.
Quote:
Is the a convention for AVRs? if I want to add a string of 16 bit words, I allocate a register pair as an accumulator, and start summing low bytes and then ad with carry all the hi bytes.
I think you need to alternate.
Quote:
But is the lo numbered register the hi byte or lo byte of the accumulator?
If you are generating an index register,
the low register needs to be R26, R28 or R30,
and the high register needs to be the next higher.
In other cases, do what you want.
They don't even need to be consecutive.
Quote:
Or does it matter and just scatter the accumulator bytes around willy nilly as available??
For the most part, willy nilly is allowed.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, good answer. I now know more about AVR register allocation convention. Thanks!

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Quote:
IF it is done properly it may be easier to understand and debug than C.
Bull.
C: a = b + c;
Write the equivalent (using integers) in asm and let's see how easy it is to understand.

But also consider

    cbi PORTC, 6
vs
    PORTC &= ~(1<<6);

I've seen a lot of beginners stumble upon that sort of C, and even experts occasionally spend a lot of time looking for the "~" that they left out. (Of course, the C code will continue to work (and is no less understandable) when PORTC becomes PORTH, while the equiv assembler starts to get rather messy...)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
when PORTC becomes PORTH, while the equiv assembler starts to get rather messy
What makes you say that? It's exactly the same for BOTH in asm...

CLRB   PORTC,6,macro_reg
CLRB   PORTH,6,macro_reg

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
CLRB PORTC,6,macro_reg
Well, if you're going to allow non-standard macros, the C code becomes equally trivial too...

(Edit: Hmm. I guess CLRB is more standard than I thought! (defined in the atmel-supplied macros.inc file.))

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Well, if you're going to allow non-standard macros, ..

Hmm, I'd say "non-standard macros" is an oxymoron!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have so much to learn still =(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We all do. :)

Regards,
Steve A.

The Board helps those that help themselves.