On 08/08/2012 04:04 PM, Michael Schnell wrote:
With volatile the code is a lot worse, I don't understand this, as
the normal code not only fulfills what is necessary to volatile ...
In fact the compiler might be right that volatile also includes
reading and writing all bytes of a variable
You are right.
My compiler also produces this absolutely decent code when not
specifying the variables as volatile.
With volatile the code is a lot worse, I don't understand this, as the
normal code not only fulfills what is necessary to volatile but even
is thread-atomic, as a thread
On 08/07/2012 08:44 PM, Lennart Sorensen wrote:
I wonder where you could get cycle counts for each instruction. I
remember seeing them years ago for 8085 and such, but no idea of
freescale provides them.
I remember that the 68332 documentation does provide cycle count. the
calculation is
On 08/08/2012 12:35 AM, Gavin Lambert wrote:
Not sure if these are applicable to the FIDO as well, but there will
probably at least be similarities.
Innovasic claims that for most instructions the cycle count is equal or
lower. But there might be some exceptions. But they don't provide a list
On Wed, Aug 08, 2012 at 05:13:53PM +0200, Michael Schnell wrote:
I remember that the 68332 documentation does provide cycle count.
the calculation is complicated, as it depends on the count of cycles
necessary to access the different memory areas that are accessed.
In fact I found that the
Quoth Lennart Sorensen:
I wonder where you could get cycle counts for each instruction.
I remember seeing them years ago for 8085 and such, but no idea of
freescale provides them.
I still have something that uses the 68332 (the original CPU32, I believe);
for that there are detailed
On 08/08/12 04:44, Lennart Sorensen wrote:
On Mon, Aug 06, 2012 at 09:59:40AM +0200, Michael Schnell wrote:
Yep. I suppose the addressing mode restriction might in fact be the
problem I see.
The examples I observed were setting bits in memory
(hardware-addressing mode: read-modify write a
On 08/03/2012 05:42 PM, Lennart Sorensen wrote:
My understanding is that the coldfire is still m68k, but has dropped
BCD support as well as some addressing modes from the instructions.
Yep. I suppose the addressing mode restriction might in fact be the
problem I see.
The examples I observed
Hi,
Some time ago I was able to build my own non-working gcc toolchain for
the 68000 but in the end, after exchanging some mails I've found out
that support for the 68000 core was 'removed' since gcc = 4.3
(I think Greg might remember this discussion)
I've filled up a bug report
On 08/03/2012 07:46 AM, Greg Ungerer wrote:
Do you know what version of gcc it uses?
Thanks a lot for answering !
fido-none-elf-gcc.exe --version
fido-none-elf-gcc.exe (Sourcery G++ 4.4-186) 4.4.1 Copyright (C) 2009
Free Software Foundation, Inc.
This is free software; see the source for
On 08/03/2012 11:48 AM, Luis Alves wrote:
At the moment I'm still using gcc 4.2.x
In fact I have been provided with a 4.4.x version.
So I am slightly better off.
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
On 08/03/2012 11:48 AM, Luis Alves wrote:
At the moment I'm still using gcc 4.2.x
I would be thankful If you could check whether in your projects, gcc
creates code that sets ad checks bits in memory and does memory/memory
operations when appropriate.
I feel
volatile int xx, xy; xx |= 0x80;
Hi Michael,
On 08/03/2012 09:07 PM, Michael Schnell wrote:
On 08/03/2012 11:48 AM, Luis Alves wrote:
At the moment I'm still using gcc 4.2.x
I would be thankful If you could check whether in your projects, gcc
creates code that sets ad checks bits in memory and does memory/memory
operations
Hi Michael,
Here is the result (gcc version is 4.2.4):
C test code used:
volatile int xx, xy;
volatile int yy, yx;
volatile int zz;
int main(void)
{
xx |= 0x80;
xy |= 0x8000;
if (zz 0x4000)
yy=yx;
return 0;
}
On 08/03/2012 03:34 PM, Luis Alves wrote:
Since the volatile tells exactly that you want to use registers during
the manipulation of those variables, so I'm not surprised that it
doesn't change memory contents directly.
Ooops.
AFAIK, volatile means something like:
this memory location is
On Fri, Aug 3, 2012 at 2:42 PM, Michael Schnell mschn...@lumino.de wrote:
On 08/03/2012 03:34 PM, Luis Alves wrote:
Since the volatile tells exactly that you want to use registers during
the manipulation of those variables, so I'm not surprised that it
doesn't change memory contents directly.
On Fri, Aug 3, 2012 at 2:45 PM, Michael Schnell mschn...@lumino.de wrote:
On 08/03/2012 03:34 PM, Luis Alves wrote:
Since the volatile tells exactly that you want to use registers during
the manipulation of those variables, so I'm not surprised that it
doesn't change memory contents directly.
On 08/03/2012 11:42 PM, Michael Schnell wrote:
On 08/03/2012 03:34 PM, Luis Alves wrote:
Since the volatile tells exactly that you want to use registers during
the manipulation of those variables, so I'm not surprised that it
doesn't change memory contents directly.
Ooops.
AFAIK, volatile
On Fri, Aug 03, 2012 at 12:13:45PM +0200, Michael Schnell wrote:
On 08/03/2012 07:46 AM, Greg Ungerer wrote:
Do you know what version of gcc it uses?
Thanks a lot for answering !
fido-none-elf-gcc.exe --version
fido-none-elf-gcc.exe (Sourcery G++ 4.4-186) 4.4.1 Copyright (C)
2009 Free
On 08/03/2012 04:07 PM, Greg Ungerer wrote:
The compiler is still free to read into a register, work on the value
and then write it back. As long as the read and the write do still
occur.
Yep I do know this. Using volatile I just wanted to ensure that in fact
the memory cell is accessed. But
On Fri, Aug 03, 2012 at 05:13:39PM +0200, Michael Schnell wrote:
I have no decent knowledge about Coldfire. I understand that
Coldfire is a kind of RISK and has different ASM code, only
providing that any 68K ASM instruction can rather easily translated
into one or multiple Coldfire ASM codes.
Hi Experts,
This is rather off-topic, but I don't know where else I might find
experts on this.
I do development for the Innovasic FIDO processor, which is an 68 K
CPU32 architecture, in fact a kind of upgrade tho the ubiquitously
used 68332 chip.
The Eclipse based IDE called Sourcery
Hi Michael,
On 02/08/12 17:33, Michael Schnell wrote:
This is rather off-topic, but I don't know where else I might find
experts on this.
I do development for the Innovasic FIDO processor, which is an 68 K
CPU32 architecture, in fact a kind of upgrade tho the ubiquitously
used 68332 chip.
23 matches
Mail list logo
