"free space" with declared type

From: Mark Piffer (sorryonly4spam_at_yahoo.com)
Date: 12/22/04 

Date: 22 Dec 2004 03:21:19 -0800

>On 21 Dec 2004 07:20:54 -0800, Mark Piffer
> <sorryonly4spam@yahoo.com> wrote:
>
>Indeed, but in practice most real-world programs don't need that
extreme
>level of conformance (anything using network or other libraries, for
a
>start).
I agree, but the task in question (a 'polymorphic' stack) is rather
only algorithmically challenging, and not exhausting the architectures
specifics.

>> How would a set of types be implemented? I can think of a union
>> containing this set, but an allocator for it would be next to
useless,
>> because you are forced to always use up storage for the largest
>> member.
>
>Yes, that's what malloc does (in fact it often wastes more than that
>because it might have to align for a type you don't need).
>
>> The alignment issues are clear to me and I don't mind them, if
>> I want general purpose alignment, it's up to the implementation,
ok.
>
>Well, you could have a separate allocator for each type. But in
>practice if you align to the largest type (not allocate in units of
that
>type, just align to it) that must work. So you can have:
>
> union BiggestType
> {
> short s;
> int i;
> long l;
> };
>
>then align the start of the allocated area to sizeof(union
BiggestType).
I think I haven't made myself sufficiently clear on this point: given
a number of completely differing aggregate types (the local variables
for the states in a statemachine e.g.) I want to stack many different
of them in my pseudo-heap. I can't exhaustively write allocators for
all types because I have only one array of char and as far as I
understand it, the allocators would need to work each on it's own
storage area.

>> I am currently implementing a file-system-like part for an embedded
>> software. The only thing that is architecture dependent is the
>> low-level access to memory, 5 out of ca. 3000 lines of C. Right now
I
>> have a setup that allows me, without touching the module itself,
>> compile and run it on an 16-bit big endian embedded as well as on
my
>> 32-bit little endian desktop machine.
>
>I work on mobile phone software, we do the same (except that reading
and
>writing flash ROM and other hardware access also has to be ported,
and
>running on several OSs with different task models means that those
>interfaces need a common layer as well).
Not imposing any task model and therefore not leaving the standard
scope in this respect is what came naturally with the construction of
a reentrant statemachine hierarchy - if I only could place my dynamic
memory (behaving nicely like a stack as I said) inside a gobal array
of char. I know that it is portable to my desktop and to many other
architectures but it is not ISO-C because the standard rather prepares
for unlikely future I-am-the-omniscient-trash-heap pointer
implementations which will cry foul if I ever touch the array of char
with another type. I can live with the aligment issue, as I said, but
the access restriction to the declared type seems artificial to me - I
hope that Chris Torek or Keith Thompson can come up with a convincing
counter argument and prove me wrong.

>How about endian and alignment issues in your structures? It is not
>possible to ever run things totally 1:1 in different environments,
and
>that's nothing to do with the language used it's because the
environment
>is part of the problem.
Nope. As I said, only in the last five or so lines the architectural
dependency shows up. Only in this place it matters to me if I write
octets or whatelse into a real memory (also, this is insignificant as
far as debugging is concerned). The big rest is pure algorithmic work
and as such expressable in standard C. Note that I do not want a 1:1
octet-wise match of my data structures on the mcu and in the desktop,
I just want it identical as far as the standard goes. All details like
different ranges, alignment, endianess and padding are of no concern
for the program logic to work, until I reach the memory interface.

>> Maybe I'm suffering
>> from a narrowed mental horizon but IMHO the standardized UB was a
bad
>> bargain for losing the "storage is storage is storage" property.
>
>If you want Java you know where it is. And it's slow and unwieldy
>because it hides all of those 'messy' things and pretends to be
running
>on the same machine everywhere (except that it fails at that as
well!).
>There is no such thing as a totally portable embedded program,
because
>by its nature it deals with things outside the C standard. You can
>however come arbitrarily close to it for the majority of the program,
>leaving the messy bits to port.
>
>Chris C

You misinterpreted me. I explicitly *do not* strive for java-ness; it
is this exact and only thing that a once declared object can't be used
as something else that I claim comes at an unjustifiable high price
for embedded programming. Don't get me wrong, I don't think that we
should go for complete anarchy in types and objects but a special case
for unsigned character is in IMHO really worth a thought. malloc is
allowed to do it, why is it impossible for the application to have
objects with no declared type but defined size?

Mark

Relevant Pages

  • Re: "available for further allocation"?
    ... well (using a cell-based allocator for smaller objects, ... It would be nice if the language of the Standard was more explicit on this matter. ... we accumulate bills into a wallet, and try to use up the smallest bills first when performing transactions. ... this can be compared to the small but frequent memory objects found in memory allocators. ...
    (comp.std.c)
  • Re: "available for further allocation"?
    ... (using a cell-based allocator for smaller objects, ... It would be nice if the language of the Standard was more explicit on this matter. ... we accumulate bills into a wallet, and try to use up the smallest bills first when performing transactions. ... this can be compared to the small but frequent memory objects found in memory allocators. ...
    (comp.std.c)
  • Re: Unions and Structures
    ... completely compiler dependent - there is no standard and you cannot ... structured binary data across architectures. ... And be very careful about sending floating point data as binary. ... same format for floating point data - not all hardware uses IEEE ...
    (comp.arch.embedded)
  • Re: "free space" with declared type
    ... because it might have to align for a type you don't need). ... you could have a separate allocator for each type. ... Most parts of the embedded software I have seen and ... > that I want rewrite the statemachines ...
    (comp.lang.c)
  • Re: Strange Porting Problem CVF to IVF, requesting help and ideas.
    ... LOC, despite having its origins early in the history of the language, ... I'm surprised that you are suprised at this not being in the standard. ... important architectures, speaking of architectural neutrality). ...
    (comp.lang.fortran)