Portability: Harmony between PC and microcontroller

  • Thread starter Tomás Ó hÉilidhe
  • Start date
B

Bart van Ingen Schenau

There were never any 16 bit ARMs, assuming you mean "16 bit" to be
descriptive of the ISA. ARM1 and ARM2 supported only a 26 bit address
space, but are pretty obsolete at this point.

Thanks. I am not familiar with the old ARMs, so my comment was purely
based on a guess.

Bart v Ingen Schenau
 
B

Bart van Ingen Schenau

Bart van Ingen Schenau wrote, On 07/05/08 14:05:


That does not show that uint_fast8_t is wrong.

But is also does not show that 'int' is wrong. That is my whole point.

An algorithm that you might want running on either a small embedded
processor or a high powered graphics workstation is one to work out the
optimum brightness/contrast setting for an image based on some
statistics. I know you might want it on a small processor because I had
to implement it on one and then later port it to another smaller
processor (in both cases HW collected the statistics, I only had to
process them in real time), and the use on a high powered graphics
workstation should be obvious. The same can apply to some other image
processing algorithms, so it does happen.

Yes, it does happen.
But do you use identical implementations of the algorithm for both the
low-powered and the high-powered device, or do you use different
implementations that make the best use of the capabilities of the
processor?

When implementing an algorithm for a high-powered architecture, do you
take it into account that the same algorithm might one day be useful
on a low-powered device (possibly without efficient floating point
support)? Or do you do it only if you already know that the code will
be ported to such a device?

My point is that supporting low-powered devices takes a lot more than
just selecting the right integer types.

Bart v Ingen Schenau
 
S

santosh

Tomás Ó hÉilidhe said:
A common novice mistake. If you use char to store numbers on a PC,
then you'll end up with code that is both slower and consumes more
memory. Slower because more instructions are needed to deal with
integer types that are smaller than the registers. Consume more memory
because you have to store those extra instructions somewhere.

This isn't necessarily true. An optimising compiler will most likely
store the char object in a system register and manipulate it as such.
So the object code is likely to use the same instructions that would've
been used for an int object.

Of course what you say could also be the case. One can't really say
without observing the actual object code.

I use int for all values below INT_MAX (or UINT_MAX) and long and long
long for bigger values. I generally won't consider short or char unless
the object is to be an array with considerable elements, in which case
the space saving may be worth it.

<snip>
 
J

jacob navia

santosh said:
I use int for all values below INT_MAX (or UINT_MAX) and long and long
long for bigger values. I generally won't consider short or char unless
the object is to be an array with considerable elements, in which case
the space saving may be worth it.

That is the ONLY serious reason for using char/short.

If you have a million of objects, then switching from int to char
and packing the structure can save you 3MB of storage. Depending on
the structure, if you have
struct foo {
char a,b,c,d;
int e,f;
};

struct foo {
int a,b,c,d;
int e,f;
};

Packing your structure can save you 100% space: the size is
3 integers in the first example (assuming 32 bit integers)
and 6 integers in the second example. For one million
copies you use 12 MB vs 24MB!

Obviously for just one copy nobody cares...
 
B

Ben Pfaff

jacob navia said:
Packing your structure can save you 100% space: the size is
3 integers in the first example (assuming 32 bit integers)
and 6 integers in the second example. For one million
copies you use 12 MB vs 24MB!

To save 100% of the space, you'd need to shrink the structure to
0 bytes.
 
T

Tomás Ó hÉilidhe

Ever written a device driver?  When interfacing with the physical world,
size matters.


For exact-size types I'd go with the likes of "uint16" in <stdint.h>.
 
J

jacob navia

Ben said:
To save 100% of the space, you'd need to shrink the structure to
0 bytes.

Obviously I mean that an increase of 12 to 24 MB is a 100% increase...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top