View previous topic :: View next topic |
Author |
Message |
ALJO
Joined: 17 Feb 2005 Posts: 2
|
Posted: Thu Feb 17, 2005 3:08 pm Post subject: Version 1.11.7.4 - comments after 15 years of c++ experience |
|
|
I have over 15 years of experience in c/c++, assembler and some basic. 7 years out of those 15, I have been developing 3D games for PC.
With my new job, I had to test the BASCOM 1.11.7.4 for the ATMEGA 128 (to see if it would work) and I would like to share some interesting discoveries about the version 1.11.7.4.
The BASCOM compiler compiles the code depending on the weather and the current concetration of moisture in the air. Let me explain.
For example. Variables passed through the function, were not always there. Sometimes they are, sometimes they are not. It feels like as the BASE POINTER would get lost. Those who know assembler, would have an idea what I talk about. Ok never the less... Let's say i was drunk. It's my fault.
Then. Interrupt #3, does not work on falling edge (like all others), but only on LOW LEVEL. Hmm... Let's say it's my fault again for some reason. But, how would you explain the fact that all other interrupts worked ok, on any settings FALLING, RISING, LOW LEVEL, execpt Interrupt #3 on LOW LEVEL. It disregarded the setting for falling edge. As if I haven't written the code. It ignored the statement totaly.
Ok, let's say is still my fault again. But, then what about this one. One global variable, named C3_ready (that's how I called it). Was seen in two different ways.
In the main loop it was 0 (zero) in the interrupt routine it behaved as 1 (one). And this lasted constantly weather interrutps were happneing or not.
Do not understand, that this was a split second... No no... This insane situation stayed like that permanently with no further interrupts occuring at all.
Now, someone would think I mixed two variables names... Perhaps I had an array going out of its boundaries, overflow, or that I HAVE NO IDEA HOW TO WORK MULTI THREADED program, and that the time-overlaping was playing with me on the variable values. Yeah right... Have been living with multithreaded programs for last 10 years. I work up to 10 threads at the time.
I have written programs 10.000 times larger in my life... and I eventually manage to remove any such bug. But here, I had only few pages of code and again the insanity of BASCOM 1.11.7.4.
Even more shocking than that. I have changed the variable NAME (!!!) from C3_ready to X3_ready and the program worked ok. Then I changed it back to C3_ready and the program had the same problem. For the same variable it saw 2 different values again (zero and one). Insane !!
And this variable appeared only in 4 different locations in the whole program. I also had another two similar variables C1_ready and C2_ready. Those two worked ok (with interrupts !!). But, C3_ready DID NOT! Bascom did not like the name. It had to be called X3_ready, instead of C3_ready and then it worked fine.
I got absolutely blown off my mind. I have no comments.
I have got more of such discoveries, but have no will to talk anymore... Does anyone know who wrote this evil thing called BASCOM ?
AL-JO |
|
Back to top |
|
|
Frankeman
Joined: 11 Aug 2004 Posts: 948 Location: the Netherlands
|
Posted: Thu Feb 17, 2005 5:32 pm Post subject: |
|
|
Hi,
Welcome to this friendly forum !
After 15 years of experience in programming you know that you must use the latest software version.
At the moment Bascom is at version 1.11.7.7
I do not know if the problem you experience is fixed in this version, but if the developer of Bascom reads your story about a hard day at the office he is willing to repair it.
(i never met him but i think he is human)
Frank. |
|
Back to top |
|
|
Luciano
Joined: 29 Nov 2004 Posts: 3149 Location: Italy
|
|
Back to top |
|
|
Evert :-)
Joined: 18 Feb 2005 Posts: 2156
|
Posted: Fri Feb 18, 2005 12:40 am Post subject: |
|
|
After 15 years experience of reading manuals;
- You can add _ at the end of a line to indicate that the line will be continued on the next line.
For example : print "this is a test" _
print " this is part of the previous line"
So, C3_ready is not a valid variable.
Regards, Evert
P.S. Try http://www.imagecraft.com for a C compiler |
|
Back to top |
|
|
Juergen
Joined: 13 Nov 2004 Posts: 85 Location: AZ, USA
|
Posted: Fri Feb 18, 2005 4:55 am Post subject: |
|
|
did you write programs at Microsoft? Sounds like it with all the newbe errors you made.... Innovation replaced by FUD.
We have several commercial programs written with BASCOM and never had such problems, neither in 1.11.7.4 nor 1.11.7.7 (maybe because my programmers are able to read manuals before they attempt to write C in a BASIC compiler?).
Juergen |
|
Back to top |
|
|
philm
Joined: 14 Jul 2004 Posts: 138 Location: Australia
|
Posted: Fri Feb 18, 2005 5:26 am Post subject: |
|
|
I have over 40 years of experience of living. One thing that I have learnt is that badmouthing and whinging like a little girl will get you nowhere. |
|
Back to top |
|
|
Werner
Joined: 27 Sep 2004 Posts: 30 Location: Germany
|
Posted: Fri Feb 18, 2005 8:51 am Post subject: |
|
|
Hallo Evert,
Quote: | - You can add _ at the end of a line to indicate that the line will be continued on the next line.
So, C3_ready is not a valid variable. |
???
I understand that I will get problems whem I'm using a variablenname like C3_, but why is "C3_xyz" not valid?
Ciao,
Werner |
|
Back to top |
|
|
ALJO
Joined: 17 Feb 2005 Posts: 2
|
Posted: Fri Feb 18, 2005 9:36 am Post subject: C3_READY |
|
|
Thanks for all your replies. Talking about the C3_ready not being a valid variable name... Can you answer then, why:
C1_Ready was a valid name and it worked fine ?
C2_Ready was a valid name and it worked fine ?
X3_Ready was a valid name and it worked fine ?
But, C3_Ready was not ?
Still my fault ?
Al-jo |
|
Back to top |
|
|
Luciano
Joined: 29 Nov 2004 Posts: 3149 Location: Italy
|
Posted: Fri Feb 18, 2005 5:15 pm Post subject: |
|
|
In VB the line-continuation character is a single leading space followed by an underscore ( _).
Luciano |
|
Back to top |
|
|
Luciano
Joined: 29 Nov 2004 Posts: 3149 Location: Italy
|
Posted: Fri Feb 18, 2005 6:38 pm Post subject: |
|
|
More test.
(The second example is just to show the limits).
Regards
Luciano
'=========================
'Example 1
'OK with VB 6.0
'OK with Bascom 1.11.7.4
Dim My_variable_a As Integer
Dim My_variable_b As Integer
Dim My_variable_c As Integer
My_variable_a = 1
My_variable_b = 2
My_variable_c = 99
My_variable_c = My_variable_a + _
My_variable_b
Print My_variable_c
'=========================
'=========================
'Example 2
'OK with VB 6.0
'NOT OK with Bascom 1.11.7.4
Dim My_variable_a_ As Integer
Dim My_variable_b_ As Integer
Dim My_variable_c_ As Integer
My_variable_a_ = 1
My_variable_b_ = 2
My_variable_c_ = 99
My_variable_c_ = My_variable_a_ + _
My_variable_b_
Print My_variable_c_
'========================= |
|
Back to top |
|
|
Calv
Joined: 08 Dec 2004 Posts: 26
|
Posted: Fri Feb 18, 2005 7:22 pm Post subject: |
|
|
I am considering a "I love BASCOM" sticker at my car. |
|
Back to top |
|
|
Calv
Joined: 08 Dec 2004 Posts: 26
|
Posted: Fri Feb 18, 2005 7:22 pm Post subject: |
|
|
I am considering a "I love BASCOM" sticker at my car. |
|
Back to top |
|
|
DToolan
Joined: 14 Aug 2004 Posts: 1384 Location: Dallas / Fort Worth, Texas (USA)
|
Posted: Fri Feb 18, 2005 8:26 pm Post subject: |
|
|
Quote: | I have over 40 years of experience of living. One thing that I have learnt is that badmouthing and whinging like a little girl will get you nowhere. |
I am a little girl with 80 years experience and I'd have to agree with philm. Whining never got me anywhere.
This is one topic I've heard lots of whining about though (comparing one language or development environment in which one has some experience to another they do not). The following comments are typical of a fellow co-worker who works with assember.
"Oh my god.... what bloatware that <insert_language_here> produces"
"What do you mean <insert_language_here> can't do that?"
"I could produce that same code in twelve bytes!"
"What a piece of $hit!"
The funny thing is, he also whined about assembler while he was learning it. The whine never changes, just the year it's produced and it's too bad you can't drink it.
I had run into problems with underscores as well. I was using an underscore as a binary seperator (example: &b1100_0101). This was acceptable in other basic compilers I was familiar with but produced mixed results in Bascom compiled code. My fix? Make a note, stop using them and move on. |
|
Back to top |
|
|
exidir
Joined: 22 Feb 2005 Posts: 1 Location: Australia
|
Posted: Tue Feb 22, 2005 4:01 am Post subject: |
|
|
Hi All,
talking about the bugs of a compiler or any kind of software has nothing to do with whinging. It is more about finding the reasons for unexplainable behaviour and maybe get the developper to have a closer look at it.
We have used Bascom for a number of quick projects and have found similar hick-ups as Aljo. I know there are a lot of heros out here, that have never found any problems in their software, but maybe they have also never done a full test of their programs. We had variables that were simply ignored by Bascom. When we disassembled the code and ran it in Atmel Studio, we found that the compiler had virtually ignored whole modules of the code.
It took me 2 days to work out, that Bascom simply does not do If-then-elseif statements, even though it claims to do it. In the end I copied the sample code and dissassembled it. Again, the whole bit of the elseif statement went missing in the compiler.
We do still use Bascom and are normally quite happy with it for small projects, but every now and then you find some real hick- ups in it.
Bascom for production code certainly requires a lot of intensive testing before the release, but that is also true for avr-gcc and similar compilers.
Has anyone ever successfully used inline assembly code in the way it is described in the manual?? Give it a try, it leads to some very funny results.
All this is based on my experience with Bascom 1.11.7.4 which was the latest version at the time of the project.
Exidir |
|
Back to top |
|
|
Ingo
Joined: 28 Jan 2005 Posts: 46 Location: Germany
|
Posted: Tue Feb 22, 2005 11:54 am Post subject: |
|
|
Hi all,
whining does not lead anywhere, also accepting errors as a fate is no solution. Errors should be named clearly and free of emotions together with the circumstances under which they appear. Then, and only then, the programmers have a chance to reproduce and to fix them. Compilers are complex things in which it is not possible to test everything under any possible condition. Proper feedback from the filed is needed for continuous improvement.
Even high professional and much more expensive compilers have bugs that are treated this way.
Hoping for further improvements,
Ingo
PS: *fast copy* and AVRco have bugs, too! _________________ Best regards,
Ingo |
|
Back to top |
|
|
|