Re: 16-bit int

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/08/2012 11:05, Göran Steen wrote:


-----Original Message----- From: David Brown
[mailto:david@xxxxxxxxxxxxxxx] Sent: den 10 augusti 2012 10:45 To:
Göran Steen Cc: gcc-help@xxxxxxxxxxx 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@xxxxxxxxxxxxxxx] Sent: den 10 augusti 2012 10:12 To:
Göran Steen Cc: gcc-help@xxxxxxxxxxx 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


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux