Re: Designing a successor to C

Discussion in 'C Programming' started by Chris Torek, Jun 27, 2003.

  1. Chris Torek

    Chris Torek Guest

    In article <>
    Arthur J. O'Dwyer <> writes:
    >C's bitwise operators work on the bits of the object, not only on its
    >value bits (AIUI). ...


    Actually, this is backwards: C's bitwise operators work on the value
    bits, with nothing specified about what might happen to any padding
    bits (if such exist).

    Most (if not all) real C implementations do not have padding bits
    in any of the types on which the bitwise operators work directly,
    so that the difference is effectively irrelevant, but the C
    standardization committee did do a lot of (possibly unnecessary)
    work to define it all.

    >Suppose ULONG_MAX is 2**32-1, represented internally as
    >
    > 0000-0000 0000-0000 0000-0000 0000-0001
    > ^^ ^
    > |bit 1 ... bit 31/sign bit
    > bit 0


    If this is "unsigned" there is no sign bit, and for unsigned
    numbers, "pure binary" representations are required in all the
    bits that participate in the value.

    >Then ULONG_MAX>>1 == 0.


    Both C89 and C99 explicitly require that ULONG_MAX >> 1 produce
    the same value as ULONG_MAX / 2. For typical actual implementations,
    this is just a logical shift.

    The real problem in C comes in with signed quantities and shifts
    that involve a nonzero sign bit. Real implementations actually
    either always do arithmetic shifts, or always do logical shifts,
    depending on the hardware. On hardware on which either kind of
    shift is equally cheap (or equally expensive -- take you pick), I
    would implement signed right-shifts as arithmetic, and hence allow
    the user to get logical shifts using unsigned integers (and I think
    most other compiler-writers would do this too). But it is not
    guaranteed, which can be annoying.

    [on allocation and writing a malloc-like routine]

    >If you know what sorts of objects you're going to have inside the block,
    >you can use the "union" trick ... [snipped]
    >And if you didn't know what sorts of objects you'd be storing ahead of
    >time, then I don't see how any extension to the implementation could
    >help you... unless the extension were to mandate a One True Alignment
    >that was a multiple of all other alignments. The One True Alignment
    >exists on all machines I have used (admittedly few), but I'm not sure
    >it *must* exist. Certainly C99 doesn't imply the existence of the OTA.


    The existence of the malloc() function, I think, implies that there
    is indeed such a thing.

    As an implementor trying to make 4.xBSD code portable across a
    collection of somewhat-similar machines, I convinced someone
    (probably Keith) to put some macros into our system headers to
    provide the numeric values of this One True Alignment. It works
    quite well, but ANSI did not adopt it back into C99 (nor did they
    adopt strsep(), nor any other number of our own inventions :) ).

    [not sure who wrote this; it appears to concern C99 compound literals]

    >>> It's not a cast. It's part of the aggregate literal.
    >>>
    >>> What is sizeof ((char[2]){'a','b'}) ?
    >>> What is sizeof ((int[2]){'a','b'}) ?
    >>> What would be sizeof ({'a','b'}) ?


    This is correct -- the thing in parentheses before the braced list
    of values in a C99 compound literal is not a cast, even though it
    resembles one syntactically.

    (The answers to the questions are: 2, 2*sizeof(int), and "error",
    respectively.)

    C99 requires the thing-that-resembles-a-cast so that a compound
    literal has a "type shape" attached to it at all times. Other
    languages will automatically infer such a type-shape as needed,
    and C *could* do this if the C99 committee had desired it, but they
    (the committee) did not, so it (C99) does not.
    --
    In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://67.40.109.61/torek/index.html (for the moment)
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, Jun 27, 2003
    #1
    1. Advertising

  2. Chris Torek

    Mark Gordon Guest

    On 8 Jul 2003 04:51:35 -0700
    (Fritz Reinders) wrote:

    > Just finished reading through this thread. It got away from the
    > original idea rather quickly :)
    >
    > For the original question of a portable language. An example solution
    > exists in the new Amiga OS.
    >
    > This is a virtual computer that has a very small very fast virtual CPU
    > & virtual peripherals. No matter what the architecture of the
    > hardware, once the CPU and peripherals core code is ported 100% of the
    > library will load and run without switches, patches, custom compilers
    > or other items that are installation dependent.
    >
    > For those who insist that a truly portable language should allow the
    > programmer to defeat the purpose of portability, it would be possible
    > to design in a pass through mechanism to allow use of the underlying
    > hardware. Useful for short term hacks, but each such hack will defeat
    > the purpose of a portable language.
    >
    > The absolute advantage to this solution is that the language best
    > suited for the task can be used.


    So for this battery powered device I am designing I should use a virtual
    machine that means

    1) Additional processor power is required reducing battery life.
    2) I have to implement a hardware abstraction later to talk to this
    custom device designed just for this one purpose.

    > This language might be Ada, C. C++, B, BASIC for quick calculations,
    > Perl, Python, PHP, <name your favorite assembly language in which your
    > million lines of need to ported code is written> for an incomplete
    > list find all the references listing computer languages past, present
    > & conceptual... it will be incomplete as there are many that have
    > never been documented :)
    >
    > Every need for performance, speed reliability, ease of use, ease of
    > porting discussed in this thread can be solved simply by writing one
    > compiler for each language and extending the compiler with features as
    > they are needed.


    So how do you extend a compiler to remove the inefficiencies of a
    virtual machine the code is going to run on?

    > The tower of Babel which you find in the compilers
    > for any given subset of a programming language is due to hardware
    > differences...remove the differences and you won't need to know the
    > nine different ways a particular lib will fail on 9 different
    > architectures.


    So you are trying to get this new product out before your competitor
    does, but first you have to implement the hardware abstraction layer
    because you are using custom hardware because there is no standard
    hardware for doing micro-scanning of this fabulous new 2048x2048 CCD
    array you have just developed?

    > For those who will focus on the example system ... it is just that a
    > functional example of pure portability. It has it's own issues and
    > problems, but IMO it is an example of a method used to implement
    > hardware irrelevance


    For a *lot* of the software industry hardware is highly relevant because
    Fred down the hall is designing this wonderful new hardware for an
    embedded system and you have to write the software for it.

    For other significant sectors customers may still have a *large* user
    base with slow machines and they may be running on slim margins. For
    example, a lot of the construction industry in the UK still have ancient
    slow machines for the people inputting invoices etc. So for those
    applications you can't afford the overhead of a virtual machine (we
    looked at Java) on the customers machines since you would just loose a
    lot of very lucrative customers.

    Also, what compiler and language do you use to write your abstraction
    layer? You can hardly write it *within* this virtual machine you are
    talking about. So you still need compilers for each specific target
    platform.

    Same for operating systems.

    For all of the things I've suggested the level of portability provided
    by C is very useful. You can generally write the bulk of your code
    portably allowing you to reuse it later for other systems or on
    different hardware whilst still being able to drop in to the word of
    implementation defined behaviour where you need access to hardware or
    non-standard facilities.
    --
    Mark Gordon
    Paid to be a Geek & a Senior Software Developer
    Although my email address says spamtrap, it is real and I read it.
     
    Mark Gordon, Jul 10, 2003
    #2
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. George W. Cherry

    Successor to Java?

    George W. Cherry, Sep 13, 2004, in forum: Java
    Replies:
    13
    Views:
    2,725
    George W. Cherry
    Sep 14, 2004
  2. Paul Hsieh

    Re: Designing a successor to C

    Paul Hsieh, Jun 24, 2003, in forum: C Programming
    Replies:
    67
    Views:
    2,374
    Edward G. Nilges
    Jul 31, 2003
  3. Dan Pop

    Re: Designing a successor to C

    Dan Pop, Jun 24, 2003, in forum: C Programming
    Replies:
    0
    Views:
    1,128
    Dan Pop
    Jun 24, 2003
  4. Chris

    Re: Designing a successor to C

    Chris, Jun 24, 2003, in forum: C Programming
    Replies:
    0
    Views:
    1,259
    Chris
    Jun 24, 2003
  5. Bruno Desthuilliers

    Re: Designing a successor to C

    Bruno Desthuilliers, Jul 1, 2003, in forum: C Programming
    Replies:
    0
    Views:
    844
    Bruno Desthuilliers
    Jul 1, 2003
Loading...

Share This Page