Keil compiler & 8051 simulator

In article <20040512.2235.299232snz@pcserv.demon.co.uk>, Paul Carpenter
<paul$@pcserv.demon.co.uk> writes
>>
>>int and short are both 16 bit on this compiler.
>
>They are on quite a few, but it is possible on some like GCC
>to force ALL ints to 32bit, which may be his problem, or how
>the link to the simulator is doing it.

As I said on THIS compiler both are 16 bits. The compiler being
discussed was the Keil compiler. 

What has Gcc got to do with this?  Just because Gcc is incorrect it is
no reason to assume other compilers will be.


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Roman Mashak <mrv@tusur.ru> wrote:

>     Thank you all for help! Problem was solved by compulsory setting
> the TR2 bit to '0' before making calculations of high & low bytes.

In other words: the problem was not that TL2 was being *set* to the
wrong value, as you claimed it was, but rather that by the time you
inspected it, the timer had already ticked up several counts from
there.

Lesson learned: if you want to observe what actually gets written into
a timer or other volatile storage, you have to set a break on the very
machine instruction that *sets* it, and check what the value being
written actually is.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

On Thursday, in article
     <BUHyG3A$3xoAFA7B@phaedsys.demon.co.uk> chris@phaedsys.org
     "Chris Hills" wrote:
>In article <20040512.2235.299232snz@pcserv.demon.co.uk>, Paul Carpenter
><paul$@pcserv.demon.co.uk> writes
>>>
>>>int and short are both 16 bit on this compiler.
>>
>>They are on quite a few, but it is possible on some like GCC
>>to force ALL ints to 32bit, which may be his problem, or how
>>the link to the simulator is doing it.
>
>As I said on THIS compiler both are 16 bits. The compiler being
>discussed was the Keil compiler. 

All compilers have options, I never said it was the problem, but
'may be his problem', which is slightly different.

>What has Gcc got to do with this?  Just because Gcc is incorrect it is
>no reason to assume other compilers will be.

He claimed in an earlier post that he was getting 32bit values (probably
finger trouble or simulator operation issue), however there are always
possibilities of misconfiguring compilation.

It is not 'incorrect' for GCC in general to do this as on some processors
some registers can be accessed as 32 bit and 32 bit operations exist for them
as well. Hence for some applications it is a choice, whether it is a
good choice is not a matter I would want to debate. For this processor
I would never remotely suggest it should be used, but some people assume
more bits is always better.

-- 
Paul Carpenter		| paul@pcserv.demon.co.uk
<http://www.pcserv.demon.co.uk/>        Main Site
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info.
<http://www.badweb.org.uk/>             For those web sites you hate.