Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Portability: Harmony between PC and microcontroller

Reply
Thread Tools

Portability: Harmony between PC and microcontroller

 
 
Bart van Ingen Schenau
Guest
Posts: n/a
 
      05-08-2008
On May 7, 8:45 pm, "(E-Mail Removed)" <(E-Mail Removed)>
wrote:
> On May 7, 8:05 am, Bart van Ingen Schenau
>
> <(E-Mail Removed)> wrote:
> > A small, handheld device is likely to be using an ARM-based processor.
> > These processors are nowadays almost universally 32-bitters. (A really
> > old ARM processof might be 16 bit).

>
> 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
 
Reply With Quote
 
 
 
 
Bart van Ingen Schenau
Guest
Posts: n/a
 
      05-08-2008
On May 7, 9:01 pm, Flash Gordon <(E-Mail Removed)> wrote:
> Bart van Ingen Schenau wrote, On 07/05/08 14:05:
>
> > This is where your reasoning starts to break down.
> > A small, handheld device is likely to be using an ARM-based processor.
> > These processors are nowadays almost universally 32-bitters. (A really
> > old ARM processof might be 16 bit).
> > Therefore, the difference between using 'int' and 'uint_fast8_t' is
> > expected to be zero.

>
> 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.

<snip>
> 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
> --
> Flash Gordon


 
Reply With Quote
 
 
 
 
santosh
Guest
Posts: n/a
 
      05-16-2008
Tomás Ó hÉilidhe wrote:

> On May 6, 8:01*pm, "Herbert Rosenau" <(E-Mail Removed)> wrote:


<snip>

>> A programmer with brain
>> for only 1 penny will decide to use the right data type that fits the
>> needs for the value it has to fit in. This will be char if the range
>> of the value fits in, it will be int, long or long long otherwise.

>
> 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>

 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      05-16-2008
santosh wrote:
>
> 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...


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
Ben Pfaff
Guest
Posts: n/a
 
      05-16-2008
jacob navia <(E-Mail Removed)> writes:

> 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.
--
Ben Pfaff
http://benpfaff.org
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      05-16-2008
jacob navia wrote:
> santosh wrote:
>>
>> 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.
>

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

--
Ian Collins.
 
Reply With Quote
 
Tomás Ó hÉilidhe
Guest
Posts: n/a
 
      05-16-2008
On May 16, 10:28*pm, Ian Collins <(E-Mail Removed)> wrote:

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

>
> 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>.
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      05-16-2008
Ben Pfaff wrote:
> jacob navia <(E-Mail Removed)> writes:
>
>> 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.


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



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
Chris H
Guest
Posts: n/a
 
      05-17-2008
In message
<(E-Mail Removed)>, Tomás
Ó hÉilidhe <(E-Mail Removed)> writes
>On May 16, 10:28*pm, Ian Collins <(E-Mail Removed)> wrote:
>
>> > That is the ONLY serious reason for using char/short.

>>
>> 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>.


And SBIT


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      05-17-2008
Chris H wrote:
> In message
> <(E-Mail Removed)>, Tomás
> Ó hÉilidhe <(E-Mail Removed)> writes
>> On May 16, 10:28 pm, Ian Collins <(E-Mail Removed)> wrote:
>>
>>> > That is the ONLY serious reason for using char/short.
>>>
>>> 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>.

>
> And SBIT
>

What?

--
Ian Collins.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
communication between matlab and microcontroller (problem with the C code) abd.hed C Programming 0 04-12-2012 11:45 AM
Review: Logitech Harmony 680 IR Remote Silverstrand Front Page News 0 06-24-2006 02:59 PM
Living with Harmony Joel Rubin Computer Support 1 06-17-2005 10:57 PM
CANON Digital Rebel/300D & Harmony remote JC - Toronto Digital Photography 0 11-13-2004 05:49 AM
Ant-contrib-0.3.jar sample and code does not work in harmony Brian C++ 1 07-29-2003 05:03 AM



Advertisments