16-bit int

[David Brown]

On 10/08/2012 11:05, Göran Steen wrote:
>
>
> -----Original Message----- From: David Brown
> [mailto:david@westcontrol.com] Sent: den 10 augusti 2012 10:45 To:
> Göran Steen Cc: gcc-help@gcc.gnu.org Subject: Re: 16-bit int
>
>
> Could you please not top-post?  It makes it very difficult to follow
> the order of the thread.  Remember that some people see these emails
> in isolation, rather than threaded in an email client.  I've
> re-ordered the mail below.
>
> On 10/08/2012 10:35, Göran Steen wrote:
>> -----Original Message----- From: David Brown
>> [mailto:david@westcontrol.com] Sent: den 10 augusti 2012 10:12 To:
>> Göran Steen Cc: gcc-help@gcc.gnu.org Subject: Re: 16-bit int
>>
>> On 10/08/2012 09:15, Göran Steen wrote:
>>> Thank you for your response.
>>>
>>> I want to make sure that my code snippets, if they are compiled
>>> and run on a machine with 16-bit int, still works. I don't have
>>> access to such a machine, so I want to compile and run them with
>>> 16-bit int on my machine that defaults to 32-bit int. Especially
>>> the intermediate results' size are interesting. What happens if
>>> they are truncated to 16-bit?
>>>
>>
>> The answer here is simple - #include <stdint.h>, and use types
>> like int_fast16_t.  If intermediary results might need 32 bits,
>> cast to int_fast32_t as needed.  On a target with 32-bit ints, both
>> these types will normally be 32-bit (though int_fast16_t could
>> theoretically be 16-bit), and the cast will do nothing.  On a
>> target with 16-bit ints, you will get 16-bit and 32-bit ints
>> respectively.
>>
>> This will give you optimal code for all sizes of target ints,
>> while also being correct on each target.
>>
>> mvh.,
>>
>> David
>
>> Thank you for your response.
>>
>> Sorry, this will not help. I want to test the snippets, not change
>> > them. Besides, I don't know if the compiler that will be used for
>> the  > 16-bit machine will support any of the types you suggest, so
>> I only  > want to use standard types.
>>
>> BR /göran
>
> If you need to test the snippets on different targets, then you need
> to have compilers and targets available.  You still haven't said
> which target(s) you are using, but unless it is one like the M68k
> then there are no compiler switches to help you.
>
> Note that there is no point in testing anything until you have done
> what you can to make sure the code is correctly written.  Otherwise
> your tests may work on some targets by coincidence, but not on
> others, or may be sub-optimal on some targets.
>
> Any C99 compiler - and almost all pre-C99 compilers - will have
> <stdint.h>.  I don't know of any compiler less than 15 years old that
> doesn't come with a <stdint.h>, and many people using such compilers
> have written their own <stdint.h>.
>
> The int_fast16_t and int_fast32_t types (and the unsigned versions)
> are mandatory in <stdint.h>, so you can take it for granted that
> /all/ compilers support them.  This is unlike the fixed-size types
> (like int16_t) that will be defined if and only if the target
> supports types of exactly that size (some architectures don't support
> the smaller types).
>
> mvh.,
>
> David
>
> Thank you for your response.
>
> I want to test the snippets with 16-bit int, without having target
> system or compiler available. You wrote that there is no compiler
> switch to help me. Thank you for that answer.
>
> BR /göran
>

Note that even though gcc doesn't have such a switch for many targets, 
there may be other 16-bit C compilers available that you can test with. 
  You /still/ haven't given any information about your systems - either 
the targets you are aiming for, or the systems you are using for 
testing.  But I am guessing (from your email headers) that you are using 
some sort of Windows system - it is quite possible that you can get a 
16-bit DOS compiler to run for your testing.

You can also test by adding some "int16_t" casts into your code - that 
will cause values to be truncated explicitly to 16 bits.

I know you don't want to change the code, but there is no way around 
this - if you want to write code that is portable across different 
integer sizes, you have to write code in the correct way.  Bad code that 
happens to test okay on one system is still bad code.

And you really should find some way to test the code on real targets - 
otherwise you are just guessing.

mvh.,

David