Need guidance,where to start C programming

However as the 8051 is an 8 bit system using the normal C programming you would use INTs which is not a good idea It slows things up and takes up too much space It is not efficient programming. The C51 Primer looks at C for efficient 8051 programming an discusses the main memory areas of the 8051 which is essential information that K&R does not cover.

However I notice from your other post you are just looking to pick a fight not be helpful

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply to
Chris H
Loading thread data ...

I feel a little sheepish proceeding. You don't really present anything factual to deal with, just brash and apparently unfounded opinion and to be honest I'm in no better shape on the comparisons. However, I feel I need to address your errors in characterizing our discussion itself -- which is what you've turned this into. Frankly, it started out with you making what you have admitted you cannot honestly make -- a conclusive comparsion -- which we now know you are ill equipped to make. My curiousity about the basis from which you spoke has been instead embraced by you as something more -- a matter of making the discussion itself the issue instead of your original claim which I wondered about. To be honest, you've answered that -- you don't know and shouldn't have spoken as you did -- but on the rest I have only a few comments below.

Jon

Well, I certainly couldn't tell this from your comment which was "I agree that over the last few years SDCC has improved greatly to 'reasonable'".. It just looks like agreement to me, not that you were citing what others said. However, I should have known. You elsewhere said you really didn't know current details about SDCC... so I should have figured what you meant to say and didn't.

I meant two things. First, before I'd make such a firm claim, "Kiel wins with no question" I'd prefer to be speaking from a position of knowledge -- because I respect the time of others and care about them. Second, if I were selling products, I'd imagine it is wise to know your competition and I'd feel pretty badly letting others know just how ignorant I was about that arena. That you feel nothing about this doesn't do you any honor, at all.

You've admitted that your opinion isn't founded on knowledge and you've shown no interest in remedying that. I'm fine if you feel fine about expressing unfounded opinions as a supposed professional; it just surprises me a little. But that too will pass.

Jon

Reply to
Jon Kirwan

In message , Jon Kirwan writes

This is not correct. I know what the Keil compiler can do. I know what an older versions of SDCC can and more importantly can not do

I have not tested the latest version of the SDCC compiler.

So as I have said several times unless there has been a complete redesign of the SDCC compiler and a complete re-write and a complete change in the way it is tested it can not compete with the Keil on several fronts. I have outlined what some of them are.

My point was why use a compiler that is technically not as good as the Keil, has not been tested as well as the Keil. More to the point as something like 80% of the 8051 professional market uses Keil why would you learn 8051 C on anything else?

Especially as due to the optimisation on the Keil system which AFAIK is not present in the SDCC the limits of the Keil Eval compiler are less important than most think.

Actually a lot of it has to do with the linker rather than the compiler

I have no time to do a full and rigorous comparison of the SDCC verses the Keil as there is no point. You can do one if you wish.

The SDCC is a nice compiler if you want to look at how a basic compiler works for interest. Some people have this irrational and religious idea that these home brewed and hobby projects have some mystical quality that means other hobby people must use them rather than the eval versions of the tried, tested, stress tested, and benchmark professional tools.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply to
Chris H

Which is the point. You made what now appears to be an ignorant claim. I prefer to check things before making such pronouncements or else simply admit my error rather than obfuscate the situation.

Which is a conditional you didn't make at the outset. I'd have been _almost_ fine with it, as you write it now. Except that I might not use the absolute phrase "complete redesign" (if I knew details about an older design) and instead choose to say "significant redesign" as a more accurate choice -- unless, of course, you happen to know enough to be able to state such an extreme, absolute. Which I doubt.

To argue that 80% (and frankly, I've no idea what the numbers are and I neither accept nor reject your assurance, except to note that I'm prone now to question most things you say or write) of the market does something and that therefore others should do it as well is what is called "band wagon" propagandizing. Unless, of course, choosing the mainstream is the important factor for the project, which it may be at times. Otherwise, it's just hand-waving.

Regarding the "technically not as good" comment, I'm now leaning far more now towards not relying much on what you say about it. You are probably right, not because you say so but more because I happen to already know how long the Keil name has been involved with the 8031 core and some of what their early teams brought to the table. So regardless of what you say about it, I would already tend to make the a priori assumption, ignorant otherwise on the issue, that they probably have had far more motivation and far more time to make a better product.

Just how much better and in what exact ways regarding these two as a current comparison is what I'm really interested in knowing. And I now realize much more than before that you aren't the one to ask about it. Despite the fact that if you were fully engaged as a caring, value added supplier of a competing product you probably should know and be able to answer on short order.

Again, I note the conditionals admitting the fact that you are not privy to the current situation.

Details?

I'm not looking for rigor. That's a strawman. But if I were a customer looking to buy Keil from a vendor, I'd expect more than what you've offered and would probably try and find someone else who knew their own products in the context of other options better before spending my money. A vendor should consider the interests of their customers over their own interests and will often, therefore, recommend potential customers elsewhere as a result if they feel they would be better served in the fuller context. Even when that means they receive nothing.

My experience with the better vendors and suppliers consistently brings this back to mind. On many occasions, and right now I'm thinking of one very recent conversation with another compiler vendor, I've been directed elsewhere towards a cheaper and/or free compiler where that seemed better for my circumstance. And done only after a careful consideration and discussion, freely engaged and without making me feel as though they were bothered by the trouble. In fact, quite the opposite -- that I felt affirmed by their honest concern.

That kind of thing brings return business, even at the loss of a sale or two.

Since I am disinclined now to take much of what you say except as anything other than self-interest, I'm not sure whether or not this is worth much. It may be the case that SDCC is good for more than that.

That's another strawman. In no way am I in that "some people" category. I have no irrational or religious ideas about homebrews. Frankly, I have a very high level of respect for commercial compiler makers and most of the vendors I've had the fortune to deal with. They are an incredible group, by and large, and their products very often worth every penny spent on them. When appropriate. However, unlike you, I also will grant the value that some compilers have for some circumstances and not belittle them out of self-interest and ignorance.

Frankly, Chris, if it isn't already manifest to you, this discussion is doing you a lot more harm that it does me (zero.) And I've decided that I'll help you keep on digging your own hole just as deeply as you keep on wanting to. If I were you, I'd stop sooner than later. This isn't doing you any good.

Jon

Reply to
Jon Kirwan

Chuck if your meaning of "C standard" means any of the ISO or ANSI ones, you should direct the OP to the 2nd ed. of K&R (although there were changes on the standard after that edition as well, but then I'll say your comment on "...simpler language..." and "covers the basic C..." contain that.

--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/
Reply to
Cesar Rabak

I don't know much more about SDCC or Keil's compilers than what I've read in this newsgroup, so I can't comment much on them. However, your statement here is not a "vote of confidence for the compiler", but a vote of confidence in the *simulator*. I'm assuming that users run exactly the same generated code in the simulator as in the final card - anything else would be lunacy. So the claim is that the object code will run the same way in the simulator and in the actual smart card processor - it says nothing about the quality or correctness of the compiler. And given the simplicity of the 8051, I would find it inconceivable that a company like Keil would make and sell an 8051 simulator that was *not* 100% correct. So it's no more inspiring than a car manufacturer claiming its headlights will run for hours at a time, and no more a vote of confidence of the compiler then the car manufacturer's claim is a vote of confidence in its engine.

Reply to
David Brown

Reasoned. Sometimes, Chris just seems to spout.

As a side note, I have already gone far enough in comparing the two to find that the same IDE and debugger system, which is provided by SiLabs and is NOT limited or hampered so far as I now know, works just as well with both compiler tools. Very well in both cases. I feel equally comfortable with either choice.

I have also taken a look at one apparent (I'm just starting to look) difference in them. Keil appears to accept 2-byte (int) sized descriptions for SFRs that are 16 bits wide and need to be posted in a fixed endian order one byte at a time, while it appears that to do the same with SDCC I have to write two statements, one for each byte. The generated code in each is equally fast and takes up the same space, but is also different.

This is actually something I consider fun to play with.

Jon

Reply to
Jon Kirwan

Doing comparisons like this *is* fun, especially examining generated assembly code. It can be particularly rewarding if you get in dialogue with the compiler authors regarding suggestions or improvements for the generated code (for open source software that's as easy as joining a mailing list - for closed source, it may or may not be easy depending on the developers).

I've seen many threads here over the years saying that Keil is the only "serious" or "professional level" compiler for the 8051, and SDCC being variously described as for hobby use, or at best for "light" professional use. As I said, I haven't used either tool - I am not even very familiar with the 8051. But I for one would value the opinion of a serious, trust-worthy and above all, independent tester. If you have enough time to do some serious comparisons and post some useful results, please start a new thread for it - I wouldn't want people to miss out because they are not following this branch.

Reply to
David Brown

I will probably do so, if I get something worth saying.

I will do that. And yes, I have the time, the inclination, and at least some useful experience to rely upon for judgment. In any case, it seems to turn out that I may also have a newly created professional interest in finding out for sure, as well. A prior discussion here was about finding a processor with an ADC I had wished for and it may be the case that SiLabs has the closest fit. If so, then this question becomes a professional one, as well. So I think the confluence of events surrounding me will drive me forward sooner than later.

Jon

Reply to
Jon Kirwan

If you have any that you feel more at home with and can suggest either links or searches that will speed my discovery of them, or are otherwise in a position to send them along to me, I'd appreciate any help very much.

Do you have a quick way for me to find them?

And thanks, Walter, for the suggestions. Much appreciated.

Jon

Reply to
Jon Kirwan

There have been a ton of 8051 C benchmarks written over the years. I would be interested in the results and comparative listings of any that you have run including the ones that are part of the Keil distribution and demo compilers. I believe that Dalton VHDL project had a few benchmarks that they used to validate their core.

The Russian benchmarks (they are essentially the same code as the ones posted for Maxq and MPS430) would give some insight into both tools sets.

Regards,

-- Walter Banks Byte Craft Limited

formatting link

Reply to
Walter Banks

Why? K&R doesn't mention INTs, which have nothing to do with standard C. It is quite possible to compile a C program to run on an 8 bit platform.

Since you didn't bother to quote, I assume you are getting nervous about the fact that I observed that your "I don't have time for ..." occurred in the midst of about 200 lines of muttering. I considered that that seemed self-contradicting.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.
Reply to
CBFalconer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.