What I don't like about assembler...

MMcLaren

Joined Feb 14, 2010
861
Oh my! That's all it does? I put it in a BoostC program for a 16F1828 and the output was 53 words of program memory (ouch!).

Anyway, thank you for taking time to explain the function. It explains a lot (lol)...

Cheerful regards, Mike
 

MrChips

Joined Oct 2, 2009
30,708
Yes, the input could be t[3]={"3",0x00,0x00}

On the LCD I want the format XX:XX:XX

So t[]={"3",0x00,0x00} needs to become {"0","3",0x00}

If t[]={"3","0",0x00} already, nothings needs to be done!

It is nothing in C, neither an array nor a string!

I simply treat it as pointer to 8-bit char.
And that can be indexed, incremented, all that!

If I wanted to, I would change it to INT pointer, and all would change to 16bit. Well almost, some minor changes required.

In assembler, I would have to rewrite everything!

The fact is that C is caring about the datatype!

But if it is a string, or array, is not much relevant. Indeed simple strings are largely the same as 8-bit element arrays.

Example yes, I simply pass the start address of my string buffer,
and run the function over it. The result is the string will always have 2 digits.
And you tell me this is easy to follow.:rolleyes:
In asm I need to do nothing. So which is better?
 

MMcLaren

Joined Feb 14, 2010
861
It's simple enough, but I was confused. I just can't imagine why you would program yourself into a situation where you have a string variable with a left justified single digit number. Is that how the itoa() function returns a string (left justified)?

BTW, has anyone figured out what the code in post #1 is supposed to do? It looks like it's trying to update a time display of some sort but the absence of any comments makes it difficult to understand. For example, what does the lcd_str() function do? I would assume it's printing the one or two ASCII digits contained in the time_buf variable. Also, what is returned from the l = lcd_str(time_buf) assignment operation? Is it the length of the time_buf string? If so, then is it possible that routine might actually print something like "0 :2 :4 " onto the LCD screen?
 
Last edited:

Thread Starter

takao21203

Joined Apr 28, 2012
3,702
It's simple enough, but I was confused. I just can't imagine why you would program yourself into a situation where you have a string variable with a left justified single digit number. Is that how the itoa() function returns a string (left justified)?

BTW, has anyone figured out what the code in post #1 is supposed to do? It looks like it's trying to update a time display of some sort but the absence of any comments makes it difficult to understand. For example, what does the lcd_str() function do? I would assume it's printing the one or two ASCII digits contained in the time_buf variable. Also, what is returned from the l = lcd_str(time_buf) assignment operation? Is it the length of the time_buf string? If so, then is it possible that routine might actually print something like "0 :2 :4 " onto the LCD screen?
Yes you guess it all right. I thought it would be a rather trivial program.

Yes it prints 0 :2 :4 originally, but I want 00:02:04.

lcd_str indeed causes the output of the characters, and l returns the length.
 

Thread Starter

takao21203

Joined Apr 28, 2012
3,702
And you tell me this is easy to follow.:rolleyes:
In asm I need to do nothing. So which is better?
Yes in assembler you sometimes hope it would work by itself, and do nothing.

So it's quite efficient, reduing programs to nothing, or nearly nothing.
 

Thread Starter

takao21203

Joined Apr 28, 2012
3,702
Oh my! That's all it does? I put it in a BoostC program for a 16F1828 and the output was 53 words of program memory (ouch!).

Anyway, thank you for taking time to explain the function. It explains a lot (lol)...

Cheerful regards, Mike
Yes it will produce rather lengthy assembler code. And what? 16K FLASH available, and it's not time critical at all. All perfectly fine!

I figured out that it is totally irrelevant if some small C function will output 50 words, or 200 words. As long as it does the job. If it is slow, then the C statement need to become reconsidered. This can both reduce size, and increase speed.

Using assembler for time critical parts of the program is the last resort.
 

Thread Starter

takao21203

Joined Apr 28, 2012
3,702
SO you are admitting that there is a place for asm.

We just dropped it from our curriculum.
:D:D:D:D:D 5 stars!

I only try to explain how I feel about assembler now, after using it for years.

Big losses in productivity, and a collection of digital waste...

How about to maintain an assembler source with 1000 or 2000 lines?
You have to think into it again, and take a lot of care all the small things, banking etc.

So making changes takes hours.

Using C, developement is 10x to 15x faster, at the cost of 2x to 3x memory footprint, and it is slower as well.

If you write good C code, it won't be much slower, it even can be faster in some instances. You can use addressing schemes that are too complex for assembler to use!

The 18f24j10 costs about $1.50 and it has 16K FLASH, as well specification is 40 MHz.

Why mess with for instance the 16f884, which has 4K, 20 MHz, and costs about $2.50??

If I only need a tiny small program, I use 16f1503, or 16f54. But even for 16f54, I would at first try to implement it in C, if can't work, simply use large MCU.

There is one assembler source which I still need to use, where I drive 4x digit LED display with a 16f54. The I/O is multiplexed, so I can input serial data. This has to be cycle exact, and response as fast as possible is required.
No question, assembler has to be used here.
 

Lourens

Joined Jul 16, 2012
15
Hi, this is my 2 cents on assembler.
Started many moons ago with pics and assembler. Because my background is industrial control, my software designs leaned towards a 'control' format. All/most functions used was in macro format. After a couple of years i had a good library of functions, so 'raw' assembly was now seldom used. Next was a .NET IDE. All macros (+- 120) now has a graphcal representation and you build your application like a circuit diagram. The addition of a communication channel between pic and pc allow the display of live values for all function blocks. So for me, as far as the microcontroller goes, assembler rules.
 

MMcLaren

Joined Feb 14, 2010
861
Would anyone mind if I take a quick stab at addressing the first couple questions from the first post?

consider the following code example:

Rich (BB code):
while(1)
    {
        if(prg_status&c_prg_status_500msec)
        {
            LC7=led_0&0x01;
            time_1sec();
            lcd_cmd(0b1010,10);
            lcd_cmd(0b1000,10);

            itoa(&time_buf,hours,10);
            l=lcd_str(time_buf);
            for(i=0;i<(2-l);i++)lcd_char(" ");
            lcd_char(":");
            itoa(&time_buf,minutes,10);
            l=lcd_str(time_buf);
            for(i=0;i<(2-l);i++)lcd_char(" ");
            lcd_char(":");
            itoa(&time_buf,seconds,10);
            l=lcd_str(time_buf);
            for(i=0;i<(2-l);i++)lcd_char(" ");

            prg_status&=(0xff-c_prg_status_500msec);
        }
    }
How much time would it take to write this in assembler?
It took an hour or so to decipher the function, due to lack of any meaningful comments, and about five minutes to write an equivalent assembly language function (with the output corrections you wanted).

How much space would it take?
The equivalent assembly language function, minus supporting library functions (just like your code), might look like this;

Rich (BB code):
;******************************************************************
;  main loop                                                      *
;******************************************************************

loop
        btfss   t500ms          ; 500 msecs? yes, skip, else
        goto    loop            ; loop (wait for 500 ms interval)
;
;  print time as HH:MM:SS on right half of first line on the LCD
;
        putcmd (line1+8)        ; lcd line 1, tab 9
        puthex (hours)          ; print hours digits
        putdat (':')            ; print ':' colon character
        puthex (minutes)        ; print minutes digits
        putdat (':')            ; print ':' colon character
        puthex (seconds)        ; print seconds digits

        bcf     t500ms          ; clear 500 msec flag
        goto    loop            ;
Your other comments and questions are difficult to address. I apologize.

Good luck on your projects and discussion.

Cheerful regards, Mike
 
Last edited:

ErnieM

Joined Apr 24, 2011
8,377
Using C, developement is 10x to 15x faster, at the cost of 2x to 3x memory footprint, and it is slower as well.
I would need some hard data to agree the penalty for C is that high.

If you write good C code, it won't be much slower, it even can be faster in some instances.
It may be the same, it ain't gonna be faster unless your compiler optimizes away large segments of your code.

I had one C program needed to fit inside 1K where I found it helpful to use assignment operators (x += y as opposed to i = i + x) as it saved a few bytes here and there. I also wrote my own multiplication and division routines, those from the built in functions were just too large to fit.

You can use addressing schemes that are too complex for assembler to use!
Assembler can do anything that C can do.
 

Thread Starter

takao21203

Joined Apr 28, 2012
3,702
Would anyone mind if I take a quick stab at addressing the first couple questions from the first post?



It took an hour or so to decipher the function, due to lack of any meaningful comments, and about five minutes to write an equivalent assembly language function (with the output corrections you wanted).


The equivalent assembly language function, minus supporting library functions (just like your code), might look like this;

Rich (BB code):
;******************************************************************
;  main loop                                                      *
;******************************************************************

loop
        btfss   t500ms          ; 500 msecs? yes, skip, else
        goto    loop            ; loop (wait for 500 ms interval)
;
;  print time as HH:MM:SS on right half of first line on the LCD
;
        putcmd (line1+8)        ; lcd line 1, tab 9
        puthex (hours)          ; print hours digits
        putdat (':')            ; print ':' colon character
        puthex (minutes)        ; print minutes digits
        putdat (':')            ; print ':' colon character
        puthex (seconds)        ; print seconds digits

        bcf     t500ms          ; clear 500 msec flag
        goto    loop            ;
Your other comments and questions are difficult to address. I apologize.

Good luck on your projects and discussion.

Cheerful regards, Mike
Thank you for your input and the work involved.

Assembler has known non-encapsulation issue.

If my code takes you one hour to decipher than I may evealute your professional mileage.

The other remarks look like kind of unneccesary traffic developed among a communication line- to me. Very subjective. If you think it's too difficult, you don't have to get involved.

I am doing things like Huffman compression, JPEG in C, and that's a bit more non-trivial. Given that above code would take you one hour to decipher, how would you get along with said codes? Or 3D programming books? Assembler?

Again, Thank you very much indeed.
 

Thread Starter

takao21203

Joined Apr 28, 2012
3,702
I would need some hard data to agree the penalty for C is that high.

It may be the same, it ain't gonna be faster unless your compiler optimizes away large segments of your code.

I had one C program needed to fit inside 1K where I found it helpful to use assignment operators (x += y as opposed to i = i + x) as it saved a few bytes here and there. I also wrote my own multiplication and division routines, those from the built in functions were just too large to fit.

Assembler can do anything that C can do.
Yes it can. One time I used a technique similar to relocation tables in MSDOS .EXE files. It was totally efficient actually. :D
 

MMcLaren

Joined Feb 14, 2010
861
Thank you for your input and the work involved.

Assembler has known non-encapsulation issue.
Sorry, I don't understand your comment.

If my code takes you one hour to decipher than I may evealute your professional mileage.
Sorry, again, I don't understand your comment. Forgive me for asking but is English your first language?

I am doing things like Huffman compression, JPEG in C, and that's a bit more non-trivial. Given that above code would take you one hour to decipher, how would you get along with said codes? Or 3D programming books? Assembler?
Actually, I'm not too bad at analyzing code and writing assembly language and C programs. It probably took the better part of an hour to realize you really coded something that would produce that flakey output. If your other programs are of the same quality, I really don't want to see them (LOL).

Once again, good luck with your projects and your discussion.

Cheerful regards, Mike
 

THE_RB

Joined Feb 11, 2008
5,438
Yes, the input could be t[3]={"3",0x00,0x00}

On the LCD I want the format XX:XX:XX

So t[]={"3",0x00,0x00} needs to become {"0","3",0x00}
...
I've done LCD clock routines etc in both ASM and C for years, and to my thinking it looks like you are trying to patch up a problem that should not have been there in the first place.

In an embedded C clock I would have used;
ByteToStr(hours,t); // get a 3char right justified string
if(t[1]==' ') t[1]='0'; // convert leading blank to leading zero
and then just displayed the string starting from t+1 which eliminates the other leading blank.

In ASM I probably would have kept hours in 2 variables; hoursH and hours so they were already stored in 2 single chars ready to display.

If I was forced to use a single var for hours, it is very fast converting to 2 digits using a subtraction algorithm even in ASM is only a few instructions;
while(hours>=10) then hoursH++ and hours-=10

I think you were making the argument that a big chunk of C is hard to write in ASM, but I think your premise is wrong. You don't take a chunk of C and re-write it in ASM, any more than you would take say a 7805 regulator and reconstruct it using 52 transistors like NatSemi used. You would design a transistor based regulator from scratch using maybe 4 transistors and a zener diode.
 

Thread Starter

takao21203

Joined Apr 28, 2012
3,702
Sorry, I don't understand your comment.

Sorry, again, I don't understand your comment. Forgive me for asking but is English your first language?

Actually, I'm not too bad at analyzing code and writing assembly language and C programs. It probably took the better part of an hour to realize you really coded something that would produce that flakey output. If your other programs are of the same quality, I really don't want to see them (LOL).

Once again, good luck with your projects and your discussion.

Cheerful regards, Mike
You are simply not benevolent towards me and/or my topic.

Language skills, as said encapsulation and all this can be subjects of esoteric elaboration.

I have come accross some larger assembler sources, some good ones, as well many bad one's.

Most I have seen were bad.

Maybe I could encourage you, after reading the thread, to consider to stop using assembler where possible? There are many misguided people who still put a lot of efforts into it.

It causes a lot of fallacious thinking as well.

In C I am mainly interested to get the job done, how it works is secondary in most cases.

Assembler will among other things cause considerable arrogance and ideas of being omnipotent (which don't correlate much to reality, control even over the chip is rather poor).

It will cause a lot of useless efforts to optimize, downto a few bytes level.

Once again, good luck with your projects and your discussion.
I would like, on this occassion, to return the benefit of doubt, and to express a good-luck wish for using any kind of assembler.

For the desire to see sources codes that I wrote, isn't it rather a question if you are into the thing they are designed for?

If you want to do...this or that...then you will look at source codes which do...this and that.

Strings handling is quite a commonplace and trivial many people deal with it. If my stuff does not work out for you, well why deal with it at all? I tend not to reply to threads when there is something that buggers me.
 
Last edited:

ErnieM

Joined Apr 24, 2011
8,377
Assembler has known non-encapsulation issue.
That depends on who writes it. I've did "encapsulated assembly" when I was developing methods to write COM objects in pure assembly.

All one needs do is organize sections into separate code modules (dot asm files) and let the linker shove them together.

The namespaces will stay local to each module.

And I can't imagine someone who uses pointers so often is NOT concerned with the well-known non-encapsulation issue of C.
 

MMcLaren

Joined Feb 14, 2010
861
Thank you THE_RB for providing a very good analogy. The discussion shouldn't be about Assembly Language vs. C, but rather having the knowledge and wisdom to know when to use one or the other (or both).
 

Thread Starter

takao21203

Joined Apr 28, 2012
3,702
I've done LCD clock routines etc in both ASM and C for years, and to my thinking it looks like you are trying to patch up a problem that should not have been there in the first place.

In an embedded C clock I would have used;
ByteToStr(hours,t); // get a 3char right justified string
if(t[1]==' ') t[1]='0'; // convert leading blank to leading zero
and then just displayed the string starting from t+1 which eliminates the other leading blank.

In ASM I probably would have kept hours in 2 variables; hoursH and hours so they were already stored in 2 single chars ready to display.

If I was forced to use a single var for hours, it is very fast converting to 2 digits using a subtraction algorithm even in ASM is only a few instructions;
while(hours>=10) then hoursH++ and hours-=10

I think you were making the argument that a big chunk of C is hard to write in ASM, but I think your premise is wrong. You don't take a chunk of C and re-write it in ASM, any more than you would take say a 7805 regulator and reconstruct it using 52 transistors like NatSemi used. You would design a transistor based regulator from scratch using maybe 4 transistors and a zener diode.
Yes I follow your explanation and would like to thank you.

I keep variables simple as uchar: hsecs,seconds,minutes,hours,wdays,days,months,and years.

As well I use the built-in atoi, which causes increase in code size, but it was 5 minutes to copy&paste it together, and it worked instantly.
Actually I have moved it into a small function, and decreased some 200 words.

Yes for the particular programming topic, it could be done in assembler without unthinkable efforts.

But it is only for example, for illustration. If you have worked out an algorithm in assembler, a collection of functions (or rather procedure) to deal with some task, it is very difficult to make major changes. In C, you can take out lines, reuse them elsewhere, because the absent banking issues, as well encapsulation can be controlled much easier.

Not to say lines are much less, 5 to 1, even more if you compress the C source. Which I do for trivial stuff which I understand well, and when it very likely does not need to become modified later on.

So you can archieve 1 to 20 compression compared to assembler, and can take it out and use it elsewhere.

Yes I also use structured programming for larger assembler sources, or let say, I have used it.

How can you build up string tables, or data tables, especially larger one's, in assembler? For sure you can come up with some clever scheme- no one will be able to understand it- and it will be tied to some specific architecture.
 

MMcLaren

Joined Feb 14, 2010
861
You are simply not benevolent towards me and/or my topic.

Language skills, as said encapsulation and all this can be subjects of esoteric elaboration.

I have come accross some larger assembler sources, some good ones, as well many bad one's.

Most I have seen were bad.

Maybe I could encourage you, after reading the thread, to consider to stop using assembler where possible? There are many misguided people who still put a lot of efforts into it.

It causes a lot of fallacious thinking as well.

In C I am mainly interested to get the job done, how it works is secondary in most cases.

Assembler will among other things cause considerable arrogance and ideas of being omnipotent (which don't correlate much to reality, control even over the chip is rather poor).

It will cause a lot of useless efforts to optimize, downto a few bytes level.



I would like, on this occassion, to return the benefit of doubt, and to express a good-luck wish for using any kind of assembler.

For the desire to see sources codes that I wrote, isn't it rather a question if you are into the thing they are designed for?

If you want to do...this or that...then you will look at source codes which do...this and that.

Strings handling is quite a commonplace and trivial many people deal with it. If my stuff does not work out for you, well why deal with it at all? I tend not to reply to threads when there is something that buggers me.
Please tell us why you feel "buggered"? That was not my/our intention. And I apologize because I really am having trouble understanding your use of language.

Regards, Mike
 
Top