|
Hi Sergio, I'm going to cut a few previous bits of the thread, the messages are starting to get huge :-) ----- Original Message ----- From: "sergio masci" <> To: <> Sent: Monday, December 06, 2004 2:03 AM Subject: Re: [piclist] Re: Proton Development Suite > I am sorry that you have taken offence but I really was not talking > specifically about your example. My statement (the one you quoted above) > came after: No offence taken, I just think code is a personal thing, almost like art :-) > Now this statement can be read in (at least) two ways: (1) yes structured > programming and parameter passing is good but sometimes you want to do > something really simple and it is frustrating to have to build functions > the > proper way, and (2) structured programming is OK but most of the time it > just gets in the way of what you really want to do. > > Someone who started out by tinkering with non-structured languages will > identify with view (2) and someone who has seen the benefit of using > structured languages will identify with view (1). > > The "structured-language-o-phobe" does tend to try to justify himself by > producing all kinds of crap because he is more intent on proving that > his inital view was right than actually moving forward and admitting that > there is a better way to do things. Agreed. I too have seen people trying to write professional code with the wrong tools, or writing crap code with the right tools, or a combination of the two. > Now again, I not trying to insult or offend you. I am not saying that YOU > are a "structured-language-o-phobe". What I was trying to say was that > people can justify themselves by producing bad code if they really want to > but > they should look at some real code produced by a competent user if they > really want to understand the benefits. I hope this has clarified what I > originally wrote. Clear as water, I get your point. > My experience has been different to yours. I have worked for many > companies > and organisations and I have found that often the comments are in error. > People do not maintain the comments with the same diligence that they do > the > code. If the use of a variable changes or the behaviour of a function > changes and the compiler spots a problem it will complain, if a bug > manifests itself it will be tracked down and fixed but when a comment is > incorrect it just sits there like a bear trap waiting to misguide you. Of course, this is correct. My comments tend to be about functionality, as I assume that the person reading the code is somewhat fluent in at least a programming language, If I write a loop that does something, such as add up an ADC reading and taking an average, I will comment "Read ADC and sum n values, then take average". This statement will remain true no matter how the loop is written, or what language it's written in, as long as the basic functionality is not lost. I don't comment really obvious things, of course, but anything that is remotely obscure I will add a comment to. I revise my comments just as I do code, I find a lot of people, as you say, read through the comments once they've been made, I tend to read everything, comments included. > The really bad thing about comments is that they move information way from > the program and into the programmer. The compiler and assembler cannot use > a > comment to verify the code or understand it any better. Using more > descriptive variable and function names does help, using sensible formal > parameters does help, using manifest constants does help, using lexical > scope does help. Agreed. I tend to do that too, and use variables with a prefix that indicates it's type, etc. > Using local variables allows you to re-use RAM previously used by one > variable for another variable. Scope helps the compiler identify which RAM > locations can be shared between multiple variables. This is like > increasing > the amount of RAM available or having a variable called dummy1 and > renaming > it for you as fred, jack and bert when it is safe to do so. Yes - the problem here is nesting. Suppose you call function A, which declares three local byte variables, and inside this function you need to call function B, which also calls three byte variables. The first three bytes from function A cannot be reused in RAM, as they have to be kept for when B ends and returns the pointer to the next instruction in A. If you start adding this up, you end up in a situation where a microcontroller's RAM fills up fast, and the stack ends up overflowing. If the compiler hasn't got good checks on this, as is the case (IMHO) with the BasicX, you run into problems as soon as you start making more complex things. You cannot escape these constraints, assuming that because Visual Basic on a PC is unlikely to have memory problems, then the same structure and calling conventions will work on a tiny uC is wrong. It is a mousetrap into which people fall very often. I have had to pull code from a function and place it in the calling function's code just because the one or two bytes it was declaring locally were busting the stack and making the uC hang. For me, there is no point in having the possibility of calling functions if I'm going to have to start shaving them off at later stages because there isn't enough RAM. > Actually yes I do expect you to be able to import other peoples code > without > any form of variable clash. Variables that are defined local to a function > cannot clash with variables that are defined as global or local to any > other > function. By using parameters to functions to pass values into functions > (not using globals) this further eliminates variable clashes. Agreed - I still stand by the stack limitation statement. Unless the compiler has a very good way of telling you the level of stack and RAM usage, this setup is dangerous for anything but simple programs, unless the coder is good and understands what is going on. Using structured code requires a lot more from the compiler IMHO. > I really have not made any judgement about you or your work. If you would > like to show me some of your work I would be happy to see it :-) Again, no offence taken - I understand the points you were trying to make, so no worries :-) I keep thinking that there is no better compiler than another, there is just a number of tools available, and I believe a competent programmer will make the best use of the one he chooses, no matter which one it is. As I mentioned, keep up the good work, I commend your effort for making a free compiler that rivals some of the expensive, commercial ones. Best regards, Mike |
Proton Development Suite
Started by ●November 17, 2004
Reply by ●December 6, 20042004-12-06
Reply by ●December 6, 20042004-12-06
|
----- Original Message ----- From: Michael Puchol <> To: <> Sent: Monday, December 06, 2004 11:52 AM Subject: Re: [piclist] Re: Proton Development Suite <snip> > Yes - the problem here is nesting. Suppose you call function A, which > declares three local byte variables, and inside this function you need to > call function B, which also calls three byte variables. The first three > bytes from function A cannot be reused in RAM, as they have to be kept for > when B ends and returns the pointer to the next instruction in A. If you > start adding this up, you end up in a situation where a microcontroller's > RAM fills up fast, and the stack ends up overflowing. If the compiler hasn't > got good checks on this, as is the case (IMHO) with the BasicX, you run into > problems as soon as you start making more complex things. You cannot escape > these constraints, assuming that because Visual Basic on a PC is unlikely to > have memory problems, then the same structure and calling conventions will > work on a tiny uC is wrong. It is a mousetrap into which people fall very > often. > > I have had to pull code from a function and place it in the calling > function's code just because the one or two bytes it was declaring locally > were busting the stack and making the uC hang. For me, there is no point in > having the possibility of calling functions if I'm going to have to start > shaving them off at later stages because there isn't enough RAM. Hi Mike, I see the problem. The XCSB compiler has ways of greatly reducing the call overheads and allowing deeper nesting but even if it is a 1000 times better I must concede that ultimately it will fail in the same way. However if you do meet such an obstacle within XCSB, you will find that there are mechanisms within it that will allow you to fiddle (greatly) with the way that RAM is allocated and if this is insufficient there are many other ways that you can direct how the executable is generated by adding or modifying a few XCASM directives. Sometimes you can do this using in-line assembler other times you would need to use a separate assembly stage BUT the important point here is that it is not a closed black box. I think one of the problems with people's perception of XCSB is that it is a compiler written for a dinky little processor so it must be a dinky little compiler. They don't seem to be aware that XCSB is actually a small component of a very complex professional tool. I actually got into PICs not because they are less capable or less demanding than bigger processors but because I wanted to be able to offer low cost modular multiprocessor control systems (e.g. http://www.xcprod.com/titan/ZMECH-DOC/generate/state-machine/block-indx.html ). Regards Sergio Masci http//www.xcprod.com |
