Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: Designing a successor to C

Thread Tools

Re: Designing a successor to C

Chris Torek
Posts: n/a
In article <(E-Mail Removed)>
Arthur J. O'Dwyer <(E-Mail Removed)> 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",

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 (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.
Reply With Quote
Mark Gordon
Posts: n/a
On 8 Jul 2003 04:51:35 -0700 Removed) (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

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.
Reply With Quote

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
Successor to Java? George W. Cherry Java 13 09-14-2004 07:03 PM
Re: Designing a successor to C Paul Hsieh C Programming 67 07-31-2003 10:21 PM
Re: Designing a successor to C Bruno Desthuilliers C Programming 0 07-01-2003 05:52 PM
Re: Designing a successor to C Chris C Programming 0 06-24-2003 05:20 PM
Re: Designing a successor to C Dan Pop C Programming 0 06-24-2003 12:01 PM