Re: native data types & efficiency

From: David Brown (david_at_no.westcontrol.spam.com)
Date: 03/08/04 

Date: Mon, 8 Mar 2004 12:05:59 +0100

"Davide" <ppp@ppp.it> wrote in message
news:c29br4$foj$1@e3k.asi.ansaldo.it...
> hello everybody,
>
> speaking in general, if I have a *XX-bit* architecture for which I'm
> developing some embedded software in some hi-level language eg. Ada, and I
> need to declare some *scalar* (not records nor arrays etc.) variable eg.
> integer: what should be better to do:
>
> 1) always declare that variable as the *smallest*data type that will hold
> the highest value of its possible range (example: if it can assume values
> from 0 to 100 then declare it as a data type represented as a byte);
>
> 2) declare the variable as the machine "native" data type, i.e. XX-bit
> represented.
>
> I think considerations should be made about efficiency and memory
occupation
> *but* (maybe) taking into account memory alignment (that could vanify
> considerations made at point 1...maybe).
>
> Waiting for your opinions,
>

There are a few things to consider when picking data sizes. In general, if
you are using Ada (or, to a lesser extent, Pascal), then declare your types
carefully with explicit ranges - this lets the compiler optomise well, and
do far better static type checking. When picking sizes for C programming,
you have to think about what you are doing with the data, and what sort of
code will be produced. As another poster has pointed out, non-native sizes
can be less efficient due to needing zero or sign extensions on some
processors, whereas on others it does not. Sizes affect storage needs
(storing 32-bits instead of 8-bits on a 63332 is unlikely to be an issue,
but it might well be if you have a large array of them), and on some chips
with half-size databuses, larger data will be slower to load or save. As an
example, for 68332 programming, I use 32-bit for local variables that are
likely to be implemented in registers, but I often use 16-bit for external
data to save databus cycles (loads don't *always* require zero/sign
extensions). But for 8-bit micros, you normally want to keep everything
8-bit if possible. Also, use unsigned rather than signed whenever possible.

You also should think about sizes if you are using arithmetic, especially on
cpus without hardware support. A 16-bit by 16-bit mulitply on an 8-bit
micro is going to be far more expensive than an 8-bit multiply.

Relevant Pages

  • Re: shifting bits
    ... In Ada, you would to an Unchecked_Conversion to an array of bits, and ... In assembler, you can only do bit-shifting on data types that have a ... This is why, in Ada, the bit-shifting operations are only defined (in ... package Interfaces) for certain sizes on modular types, ...
    (comp.lang.ada)
  • SUMMARY: Copying a saveset to disk.
    ... what files it has and the physical record sizes. ... Exercisers" subset so you might need to load it from the install media, ... The contents of this email and any attachments are sent for the personal attention ...
    (Tru64-UNIX-Managers)
  • Re: loading Tornado 2.2 .out image on a Tornado 2.2PNE BSP machine
    ... trying to load an .out file compiled with Tornado2.2 to that machine. ... Relocation value does not fit in 24 bits ... application that its text and data section sizes are more then 32MB? ...
    (comp.os.vxworks)