Frustrations... [modified]
-
Can you post a minimal program that reproduces this bug, with details of the compiler version you are using?
Nishant Sivakumar wrote:
Can you post a minimal program that reproduces this bug, with details of the compiler version you are using?
No... it's a custom platform. It compiles C and ASM. The target device is an Atmel Diopsis D740 (ARM processor + mAgic DSP). The IDE (if we can call is so) is MADE (Multicore Application Development Environment) 1.6 Beta, written by Atmel, as well as the compiler (that occasionally spits out "internal compiler error"s :wtf: without any reason). The ARM and the DSP execute different functions, different
mains and so on. The ARM can start and stop the DSP using theRUNMAGICandWAITSYSTEMmacros. You can exchange data between the 2 processors using a shared memory area (2x512 40-bit words). You have to use semaphores to sync them. The whole IDE is buggy. I should try to run the code directly on the test board, but I cannot until monday. ______________________________________ Tozzi is right: Gaia is getting rid of us. My Blog [ITA] and the ScrewTurn Software experiment -
It's possible that *p_semaphore in a pointer to a floating point value and the value is less than 1, but not zero. The %d in the printf rounds it down. (It also could be a pointer to an __int64 and the value of the lowest 32-bits is zero. The printf truncates it.) Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Joe Woodbury wrote:
It's possible that *p_semaphore in a pointer to a floating point value and the value is less than 1, but not zero. The %d in the printf rounds it down.
All the values are integers (volatile unsigned long long, 40-bit on that platform). ______________________________________ Tozzi is right: Gaia is getting rid of us. My Blog [ITA] and the ScrewTurn Software experiment
-
In the actual code there are all the brackets, because some comments have been added inside the cycle. No, it's not a "program" error, it's definitely a bug of the simulator (one of the many known bugs). The whole platform is still a evaluation sample (I use it in my University), the IDE/simulator is still in beta (I think the first release is dated 235 A.C. :-D). ______________________________________ Tozzi is right: Gaia is getting rid of us. My Blog [ITA] and the ScrewTurn Software experiment
-
In the actual code there are all the brackets, because some comments have been added inside the cycle. No, it's not a "program" error, it's definitely a bug of the simulator (one of the many known bugs). The whole platform is still a evaluation sample (I use it in my University), the IDE/simulator is still in beta (I think the first release is dated 235 A.C. :-D). ______________________________________ Tozzi is right: Gaia is getting rid of us. My Blog [ITA] and the ScrewTurn Software experiment
-
Joe Woodbury wrote:
It's possible that *p_semaphore in a pointer to a floating point value and the value is less than 1, but not zero. The %d in the printf rounds it down.
All the values are integers (volatile unsigned long long, 40-bit on that platform). ______________________________________ Tozzi is right: Gaia is getting rid of us. My Blog [ITA] and the ScrewTurn Software experiment
Dario Solera wrote:
unsigned long long
I still think that's the problem--the printf %d is apparently truncating the value. One way to verify this is to compile to assembly code if possible and examine that directly. Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Dario Solera wrote:
No, it's not a "program" error, it's definitely a bug of the simulator
Too bad. Have fun with that.
Bob X wrote:
Too bad. Have fun with that.
Thanks. :-D ______________________________________ Tozzi is right: Gaia is getting rid of us. My Blog [ITA] and the ScrewTurn Software experiment
-
Dario Solera wrote:
unsigned long long
I still think that's the problem--the printf %d is apparently truncating the value. One way to verify this is to compile to assembly code if possible and examine that directly. Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Joe Woodbury wrote:
I still think that's the problem--the printf %d is apparently truncating the value.
I think not, because in other programs (written by other people) the thing works. :) ______________________________________ Tozzi is right: Gaia is getting rid of us. My Blog [ITA] and the ScrewTurn Software experiment
-
Joe Woodbury wrote:
I still think that's the problem--the printf %d is apparently truncating the value.
I think not, because in other programs (written by other people) the thing works. :) ______________________________________ Tozzi is right: Gaia is getting rid of us. My Blog [ITA] and the ScrewTurn Software experiment
Dario Solera wrote:
I think not, because in other programs (written by other people) the thing works.
That's irrelevent since we know the code doesn't work. You could have an optimization bug, which might explain why it apparently works in slighty different sitatuations. You really need to examine the machine code being created. Another issue is whether this only fails in the emulator or also when using the target hardware? Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Before you go on: this is not a programming question. I'm working on a project, using a development environment that simulates the code execution for a specific device. At some point there is this piece of code:
while(*p_semaphore != 0) printf("Sem: %d\n", *p_semaphore);
Know what? The output on the console is an infinite series of:
Sem: 0
Sem: 0
Sem: 0
...How the hell is this possible??? :mad: Note: this is not a question. It's just a report of how sometimes your work makes you really pissed-off. :sigh: ______________________________________ Tozzi is right: Gaia is getting rid of us. My Blog [ITA] and the ScrewTurn Software experiment
Sounds like a bug in the compiler. I assume it's for an embedded system. It's shocking how buggy some of those compilers are. It really makes you appreciate desktop compilers and how stable they are in comparison. I knew some embedded system developers that were going crazy a few years ago because their old compiler couldn't always make a simple post increment (index++) work. Now that's bad!
-
Dario Solera wrote:
I think not, because in other programs (written by other people) the thing works.
That's irrelevent since we know the code doesn't work. You could have an optimization bug, which might explain why it apparently works in slighty different sitatuations. You really need to examine the machine code being created. Another issue is whether this only fails in the emulator or also when using the target hardware? Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Joe Woodbury wrote:
You really need to examine the machine code being created.
That's not easy at all. There is a (sort-of) disassembler, but I have to look through 2 different ASM references, and many platform-specific instructions. It could require days. I'm quite sure I wouldn't be able to find the problems. I have also to talk with my project-fellow.
Joe Woodbury wrote:
Another issue is whether this only fails in the emulator or also when using the target hardware?
I'm waiting to test it, on monday. ______________________________________ Tozzi is right: Gaia is getting rid of us. My Blog [ITA] and the ScrewTurn Software experiment
-
Sounds like a bug in the compiler. I assume it's for an embedded system. It's shocking how buggy some of those compilers are. It really makes you appreciate desktop compilers and how stable they are in comparison. I knew some embedded system developers that were going crazy a few years ago because their old compiler couldn't always make a simple post increment (index++) work. Now that's bad!
Joshua Quick wrote:
Sounds like a bug in the compiler.
There are many known bugs in the compiler. :doh:
Joshua Quick wrote:
I assume it's for an embedded system.
True: Atmel Diopsis D740. It's quite cool (theoretically): the DSP computes 1 GFlop at 100 MHz, using some pipelines and vectorial engines. In my case it seems that when you set a variable (*p_semaphore, for instance), in some cases the value is not stored! An this happens *many* times, but not all the times: during a
forcycle, for example, some assignments are actually executed, some other are not :wtf:. I think it depends on the "history" of the operations you executed before, or when you activate different components. Maybe the fined state machine of the simulator is broken. At least I hope so. Next monday I'm going to test it directly on-board. ______________________________________ Tozzi is right: Gaia is getting rid of us. My Blog [ITA] and the ScrewTurn Software experiment -
Before you go on: this is not a programming question. I'm working on a project, using a development environment that simulates the code execution for a specific device. At some point there is this piece of code:
while(*p_semaphore != 0) printf("Sem: %d\n", *p_semaphore);
Know what? The output on the console is an infinite series of:
Sem: 0
Sem: 0
Sem: 0
...How the hell is this possible??? :mad: Note: this is not a question. It's just a report of how sometimes your work makes you really pissed-off. :sigh: ______________________________________ Tozzi is right: Gaia is getting rid of us. My Blog [ITA] and the ScrewTurn Software experiment
I feel your pain, not trusting the tools is quite annoying :) At first this looked like a missing
volatilekeyword on p_semaphone but that still doesn't explain the behavior. Good luck. -
I feel your pain, not trusting the tools is quite annoying :) At first this looked like a missing
volatilekeyword on p_semaphone but that still doesn't explain the behavior. Good luck.Henrik Husted wrote:
At first this looked like a missing volatile keyword on p_semaphone but that still doesn't explain the behavior.
I have been suggested, since the beginning, to use always
volatile, and so I did. :) ______________________________________ Tozzi is right: Gaia is getting rid of us. My Blog [ITA] and the ScrewTurn Software experiment