so it's playing out like post #3 after all...

Well this is a new twist on the old debate. I've never seen reinforcements brought in from other forums. how exciting!

 

Well this is a new twist on the old debate. I've never seen reinforcements brought in from other forums. how exciting!

It is kind of containing the crisis. As long as it does not spread out into other threads?

I have various 68000 chips still here, some were actually sold off, with some profit.

If I consider PIC32 will likely already be far more powerful than plain 68000, why put big efforts into it anymore?

As mentioned, PIC32 + assembler would be true bare metal hardcode hacking. I am not going to have it.

 

Well this is a new twist on the old debate. I've never seen reinforcements brought in from other forums. how exciting!

Awaken the Troll army! Hmm, or is the Anti-Troll army?

Takao, I agree with you on many points and myself use C for 98% of my PIC coding these days, with some little bits of assembler thrown in for speed when needed.

I don't think people are against your opinion because of you saying C is better , but because you took a VERY "black and white" attitude on a large and complex subject.

Maybe we should classify "C vs ASM" as a religious discussion? In some threads it seems to bring out a similar behaviour, and that's a generalisation (not aimed at anyone here).

 

Yes I agree. As you have seen my new thread for string tables, I do use assembler sometimes.

People seem to misunderstand me.

I wrote "What I don't like about assembler".

I would welcome really replies containing things like "I used assembler for this and that, and my experience was...".

It is not clear if these who replied have ever been involved with larger assembler sources.

Assembler is no longer present in Visual Studio. But the debugger is powerful enough so that it is no longer needed to go into the depths of the code.

For PICs yes it is helpful to look at the disassembly, when things don't work out.

Myself I have started programming with BASIC. When I was younger, and have tried for instance TURBO C, it was very difficult for me to do the abstraction. I did not get along with it well.

Only with the support of Visual Studio I was able to learn C++.

Well I was sometimes looking at old assembler sources for the AMIGA video game console, and I was thinking, what a waste, all the creativity buried and chained to the 68K instruction set. And that instruction set is considered as comfortable, having multi-bit shift, MUL/DIV, many registers, and powerful addressing modes.

The recent replies aren't really useful for the topic, not at all.

And the purpose of the thread, well I think people should become warned of Assembler, including to have explanation available what issues will occur.

Really clearly something like: "Don't use Assembler to start to learn programming, and don't use it exclusively for larger programs. It will hold back your productivity by factor 10, among other things".

 

I would welcome really replies containing things like "I used assembler for this and that, and my experience was...".

I'm afraid I did not enjoy a very welcoming experience.

When I replied in post #50 to the two questions in your original post, I was met with criticism. It seems you were not really interested in anyone answering your questions or hearing from anyone with positive experiences using assembly language. And so it seems the purpose of this thread is to promote your opinions and dislike for assembly language and to criticize anyone who actually knows how and when to use assembly language effectively.

I think your behavior is disturbing and sad and that's why I avoided engaging you on Forum.Microchip and Electro-Tech-Online. I'm embarrassed that I didn't recognize who you were in time to avoid engaging you here. My mistake...

 

I think you behavior is disturbing

I think Nigel Goodwin from Electro-Tech is disturbing too.

I would welcome as he runs this forum if he disclaims who he is. Even if I am not going to notice as I never even read posts there.

However I could not imagine to see someone like him on the MSDN forums, and for instance saying "Most of your posts are rubbish".

Or how about "We are a group of Windows Haters"?

If LINUX would get out of fashion, I would not really miss it, or bother about this. Free software can make sense, but it also has attracted the wrong kind of people. I don't hate it. I even use Linux webhosting.

Maybe most of my posts here are rubbish too.

Some of the replies here are nothing but Yakuza communications, a more polite form to tell people actually to shut up.

Embarassing? There have been some user emblems on Wikipedia quite a few years ago, when the same community was much smaller.

Wikipedia is where my online problems started, and some notorious individuals have indeed carried it all over through various public forums.

I must also say I have (online) observed various professional assembler users, and some of them are remarkably arrogant. And you contribute to this observation.

It is also true people who have things to hide seek mistakes in other people, to distract from this.

Maybe thinking in assembler causes things to our brains that we yet have not fully understood. I am afraid I do believe it has such effects.

What I really can't stand on forums are people who produce negative communications, but often not even one circuit they have built can be seen. No profile photo, no website either.

Like an unemployed father, his son has stolen, and he tells him "Your behaviour was bad, I need you to make pay for this". Instead to get a life himself, and give a good example that speaks for itself.

You don't like my circuits? Do it better.

I don't really care if I get banned from forums. This has happened. They are simply anally. There are also forums where I know that I won't get banned for my behaviour as it is.

Maybe I should spend some time again with rail FPS games. Lengthy argumentation will be absent. I don't get overexcited about doing this car park again, but it helps.

 

Here is some big A as well:

unsigned char get_b(const char* a,unsigned char idx)
{
    ab=a;
    ab0=ab;
    ab1=ab>>8;

    STATUS=0;
    ab2=idx;

#asm
GLOBAL _ab,_ab0,_ab1,_ab2,_x
    MOVF (_ab0),W
    movwf 0x0a
    movf (_ab1),W
    MOVWF 0x0b
    call 0xf1
    movwf (_x)

    movf (_x),W
    movwf 0x0a
    movf (_ab2),W
    addwf 0x0a,f
    movf (_ab1),w
    movwf 0x0b
    call 0xf1
    movwf _x
#endasm
    return(x);
}

Particulary the urge to start this thread has come to existance, when recently I have skipped through assembler sources codes for Microsoft BASIC.

How can anyone want to do something like this nowadays?

And what I refer to is mainly to write programs exclusively in assembler.
But also including to do all this disassembly and hacking stuff.

It must have taken many hours, weeks or months to disassemble these ROMs, to understand how the BASIC works, and to write the documentation.

I was only thinking, what a waste. At least if it has been the only activity of this person.

 

Ok boys, have at it. I'm unsubscribing to this thread.

 

Maybe it could become closed. Or deleted.

Before it will cause 20,000 emails to become sent.

I have at least digged out this 16f59 LED matrix circuit, and I rewrote the control program in C. Including to have a little assembler code.

For some of the replies, I am unsure what kind of action I should initiate or consider or perform, if any.

 

First of all, I would like to ask strantor not to put oil in a de facto hot thread.

Now, I 'd like to say to the OP that making absolute statements of the type "Assemblers aren't useful at all nowadays" is asking for hostile comments.
Everything that exists has a use, even though it's not apparent to you or me. Take into account the many uses of software and the various instances at which they are implemented and then consider your statement again.

I will not lock the thread, since there haven't been serious infractions of the ToS. We 've seen worse.

Keep it civilized, people.

 

If you build up a library of standard subroutines and macros assembler is as easy as C.

 

If you build up a library of standard subroutines and macros assembler is as easy as C.

That's what I do. I wasn't going to get involved in the discussion but IMHO you nailed it! I use C when I think its appropriate. But I also have a standardized .asm framework for PICs that I can get out and populate with tried and true, compact and fast code using macros and libraries. Its just my thing. I work mostly in 8 bit PIC. While I've done a bunch of C on the 18F and XC8 looks OK, I don't think any of the 8bit PICs are a particularly good C platform.

 

That's what I do. I wasn't going to get involved in the discussion but IMHO you nailed it! I use C when I think its appropriate. But I also have a standardized .asm framework for PICs that I can get out and populate with tried and true, compact and fast code using macros and libraries. Its just my thing. I work mostly in 8 bit PIC. While I've done a bunch of C on the 18F and XC8 looks OK, I don't think any of the 8bit PICs are a particularly good C platform.

I respect that as your opinion.

However, also C can be "played", for instance in terms of optimization, both for program space, and speed. Normally this is neither difficult, nor takes long time.

Bad C code can take 5x to 10x runtime + double code space or more.

It is also possible to cut down C code, for instace remove I2C delays/error checking, for a slow device, and when errors make no difference and/or are unlikely to occur.

You can optimize assembler this is correct, and it might be faster than C code. Depending on the complexity, it will be stretching over 3 to 5 pages, or more. How can you try new ideas on such a source, and change it within a few minutes?

I wrote a text scrolling algorithm in assembler (using for instance proportional fonts, and allowing variable display width). Stretching over 10 pages at least! I found it nearly impossible to maintain in terms to make major changes to the algorithm.

I coded it again in C. It is about 2 pages altogether. And it is very easy to change/maintain/etc.

Since I use C code that is geared towards PIC architecture, there won't be so much difference to assembler. If I use a one-bit shift, or by-one increment, and exploit this in the so-called "inner loop" to do things, the C compiler only sets banking bits, and does the shift. Not much else!

What I particulary like about using C on 8-bit PICs is the fact you can use 16bit variables, if you need it, and the resulting lengthy assembler code is hidden...so to say.

Optimizing C code means for instance never to compute complex expressions twice. In assembler you can buffer results too- maybe. If you have the right banking bits set + a FSR available. But that is often not the case when coding some algorithm that needs the FSR + sets banking bits for own purposes. Reloading the same / buffering the FSRs results in lengthy, messy assembler code, can improve speed but is bad to maintain.

 

I respect that as your opinion.

I respect yours as well. We are all products of our training, temperament and experience. Myself, I've had lots of all of it. So in the spirit of exchange, let me pick at some things in your reply. (Apologies to those in the previous 10 pages if its already been pointed out).

C can be "played", for instance in terms of optimization, both for program space, and speed. Normally this is neither difficult, nor takes long time.

This should be printed on page 1 of every compiler manual! Knowing something about compiler design helps but when starting a new compiler, I ALWAYS run some test code with standard constructs to see how the compiler generates the target code. Off the top of my head, I can tell you that PICC-18 (HiTECH- my version anyway) makes way better code when:

1) you cascade bit variable tests instead of ANDing them together (makes successive btfsx instructions instead of evaluating, saving, goto the next test etc.)
2) System variables are global. This allows address generation at compile time and supports locality i.e. direct banked RAM addressing. Calculating addresses for 'extern' variables means generating run-time address calculation which is more code.
3) One dimensional arrays are more efficiently accessed by indexing rather than pointers. I'm surprised, too.

There's more, including ROM access via tables etc. but you get the idea. Anyway, YES, good call.

You can optimize assembler this is correct, and it might be faster than C code. Depending on the complexity, it will be stretching over 3 to 5 pages, or more. How can you try new ideas on such a source, and change it within a few minutes?

The same way you do it in C or any other language, with structured/modular programming. One task, one routine. Small files. I had to visit a project today so did some looking at how I did it. The project had 112 source files. Each file (or small group of files) had code that performed some specific function. Each function was well defined i.e. read the ADC, give me degC and flag if its valid. The project is large with lots of functionality but when I need to change/update something (we recently replaced the external ADC with another) its a few changes in a file and everyone else doesn't know the difference. Easy.

Since I use C code that is geared towards PIC architecture, there won't be so much difference to assembler. If I use a one-bit shift, or by-one increment, and exploit this in the so-called "inner loop" to do things, the C compiler only sets banking bits, and does the shift. Not much else!

You are kind of making my point here. Properly written .asm code can take advantage of knowing where things are at build-time. The result is that you can set the banks ONCE for each routine, then have at it. Your compiled example has to set RP1/0 then do the bit shift. Once I'm located in the bank, I can run wild until its time to exit without having to take time/space to maintain RPx. (or IRP for that matter).

I know it may not seem like much, and it isn't.. until you run out of program space.. which I have.. even IN assembler.

What I particulary like about using C on 8-bit PICs is the fact you can use 16bit variables, if you need it, and the resulting lengthy assembler code is hidden...so to say.

I have 16-24-32 bit fixed point libs for the 16xxx stuff. For the 18F, all of the same plus IEEE-754 floating point on the 18F. Since the 18F has lots more memory, I also have macros that do simple math inline. I fully appreciate your position though.. Its a beating and sometimes, I DO envy the C guys. But when I gets that far.. I really envy the ARM guys..

If you have the right banking bits set + a FSR available. But that is often not the case when coding some algorithm that needs the FSR + sets banking bits for own purposes. Reloading the same / buffering the FSRs results in lengthy, messy assembler code, can improve speed but is bad to maintain.

One of the many reasons I don't use the 16xxx any more. The 18F is far superior in every way. Its hard to get this point across sometimes. Maybe its the 'simple to learn 33 instructions' thing. Personally, I kind of like advanced computer-science methods like add-with-carry and.. watch out now.. hardware multiply. Multiple FSRs that span addressable RAM, with auto-inc/dec.. please! I can't take it. But, after 150+ 10xx/12xx/15xx/16xx/17xx deliveries, I don't accept any new 8-bit PIC projects that are not 18F based unless there is a VERY compelling reason to do so.

I don't think any of the 8bit PICs are a particularly good C platform.

Sure. While you (and I) can write C for PIC and deliver projects, none of the 8 bit PICs have a real addressable stack. The RAM is banked. In the 16xx, the ROM is banked with 8 louzy call levels to boot. C is a stack-based language that expects linear address spaces so the compiler authors have to improvise, and do things like adding banking instructions. And banked ROM/RAM means that the compiled code will likely contain unnecessary bank flips because where things are is not known at compile-time and the linker (which DOES know) can't re-jigger the code after compilation. Its not a knock on the compiler guys, they do a good job with what they have to work with. But if you push it, you may get to the point where you are fresh out of PIC. Personally, over the years, I've run out of all of it.. ROM, RAM and Tcycs (in assembler, too). For me, that gets expensive.. fast. But in assembler, I can streamline, localize and optimize far better than any PIC compiler to date, even XC8.

Wow, that's a lot. Probably the place to leave it is the first statement... We are products of our collective experience. I've tripped up lots trying to pack 6 kilos into a 5 kilo box. While you don't get a refund on the unused code that your super-optimized C or assembler generates, you likewise get no sympathy when you bust a bank or flat run out of resources. You just miss dinner.