Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #26384 > unrolled thread

Re: Wanted: C or C++ compiler for Intel 8031/8051 ***

Back to article view | Back to comp.arch.embedded

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Wanted: C or C++ compiler for Intel 8031/8051 *** kevinferg@gmail.com - 2017-04-18 09:50 -0700
    Re: Wanted: C or C++ compiler for Intel 8031/8051 *** Dimiter_Popoff <dp@tgi-sci.com> - 2017-04-18 20:43 +0300
    Re: Wanted: C or C++ compiler for Intel 8031/8051 *** Tim Wescott <seemywebsite@myfooter.really> - 2017-04-18 12:57 -0500
      Re: Wanted: C or C++ compiler for Intel 8031/8051 *** George Neuner <gneuner2@comcast.net> - 2017-04-18 15:30 -0400
        Re: Wanted: C or C++ compiler for Intel 8031/8051 *** Grant Edwards <invalid@invalid.invalid> - 2017-04-18 20:05 +0000
          Re: Wanted: C or C++ compiler for Intel 8031/8051 *** mac <acolvin@efunct.com> - 2017-04-20 21:42 +0000
    Re: Wanted: C or C++ compiler for Intel 8031/8051 *** habib <h.bouazizviallet@free.fr> - 2017-04-24 22:18 +0200
      Re: Wanted: C or C++ compiler for Intel 8031/8051 *** George Neuner <gneuner2@comcast.net> - 2017-04-25 16:07 -0400
        Re: Wanted: C or C++ compiler for Intel 8031/8051 *** Robert Wessel <robertwessel2@yahoo.com> - 2017-04-26 00:17 -0500

#26384 — Re: Wanted: C or C++ compiler for Intel 8031/8051 ***

I endorse everything Charles Manning said on this topic, and couldn't have said it better, but I will generalize it a bit:

The whole point of high level languages is abstraction.  That means hiding the details, and handling them behind the scenes so that the programmer need not worry about them.    C++ has a much higher level of abstraction than ANSI-C, which makes it all the harder to keep track of the details that will cripple your poor little processor.   Everything the processor does is in machine code, which means there is nothing that can be done in C++ that can't conceivably be done in assembly.  Yes many things would become nightmarish, but that is exactly the nightmare your processor is dealing with at run time.

The fact that very high level languages can make very complex tasks rather simple to program is not a plus when those tasks have to run on austere hardware.  Having some sort of parity between the abstraction level of the programming language, and the hardware resources is a good check on asking too much of the hardware.
  

  

[toc] | [next] | [standalone]

#26385

On 18.4.2017 г. 19:50, kevinferg@gmail.com wrote:
> I endorse everything Charles Manning said on this topic, and couldn't
> have said it better, but I will generalize it a bit:
>
> The whole point of high level languages is abstraction.  That means
> hiding the details, and handling them behind the scenes so that the
> programmer need not worry about them.    C++ has a much higher level
> of abstraction than ANSI-C, which makes it all the harder to keep
> track of the details that will cripple your poor little processor.

Processor resource utilization is a valid point but not the
worst consequence of doing things too much at high level.
The worst part is the fact that as the high level hides the details
these details become a nightmare to access for the programmer.
And engineering is about the details, programming may have things
in common with writing generic prose but it is certainly not the
same thing.
High level languages are very good at tasks which one has to
complete in a few days; much like using a phrase book in a country
which speaks a language you don't know.
But if the effort is to take many months or years high level becomes
only a constraint, pretty much like a phrase book level language
skill would be limiting if you have to live in a country for years.

OTOH, there are various languages - some (like English and others,
all alphabet based) - have been used to write masterpieces. Others,
(mainly hieroglyph based) have been much less successful at that.
So choosing between staying at phrase book level and learning
the language may be a pretty hard thing to do.

> Everything the processor does is in machine code, which means there
> is nothing that can be done in C++ that can't conceivably be done in
> assembly.  Yes many things would become nightmarish, but that is
> exactly the nightmare your processor is dealing with at run time.

Things can be nightmarish indeed. For example, it would be insane to
write using the native codes of a RISC processor (which would also
be a load/store processor thus one would have to be explicit with
all the loads, stores etc.). Doable but impractical. The 68k assembly
was completely different, it was quite practical to write
anything using it. However the language - being as good as it was - put
too much on the hardware, eventually the 68k architecture became
obsolete.
I happened to have a lot (many megabytes of sources) written in
68k assembly back then (almost 20 years ago). It was (still is)
good code, I rarely write things in a way so I might want/have to
rewrite them later.
This was behind my decision to make (invent?) vpa (virtual
processor assembly) which would take 68k sources and produce
binary code for modern day processors (PPC back then, called "power
architecture" nowadays).
Of course things did not stay at the 68k level (although user
level code (cpu32 style) will still compile). First it took a few
minor but key expansions which were obvious enough and I did them
at the very start to make the language a lot more liberating
than 68k assembly was (e.g. 3 operand operations - like in
power, source1-source2-desitnation, however not restricted to registers,
operation modifiers propagating into condition code update or not
etc. Things gradually got more complex, macro argument/partial
access, access to dps script named variables with names made
up of variables etc. etc.
As it is now I would be very surprised if anyone could match
(using his language of choice) what I can do using vpa
in a say 6 months project spending the same time.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#26386

On Tue, 18 Apr 2017 09:50:26 -0700, kevinferg wrote:

> I endorse everything Charles Manning said on this topic, and couldn't
> have said it better, but I will generalize it a bit:
> 
> The whole point of high level languages is abstraction.  That means
> hiding the details, and handling them behind the scenes so that the
> programmer need not worry about them.    C++ has a much higher level of
> abstraction than ANSI-C, which makes it all the harder to keep track of
> the details that will cripple your poor little processor.   Everything
> the processor does is in machine code, which means there is nothing that
> can be done in C++ that can't conceivably be done in assembly.  Yes many
> things would become nightmarish, but that is exactly the nightmare your
> processor is dealing with at run time.
> 
> The fact that very high level languages can make very complex tasks
> rather simple to program is not a plus when those tasks have to run on
> austere hardware.  Having some sort of parity between the abstraction
> level of the programming language, and the hardware resources is a good
> check on asking too much of the hardware.

How old is the thread that you didn't bother quoting, thus leaving all of 
us with real newsreaders in the dark?

AFAIK, the SDCC works with the 8051, and the project is still active.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

[toc] | [prev] | [next] | [standalone]

#26387

On Tue, 18 Apr 2017 12:57:46 -0500, Tim Wescott
<seemywebsite@myfooter.really> wrote:

>How old is the thread that [kevinferg] didn't bother quoting, thus leaving
>all of us with real newsreaders in the dark?


I'm guessing it's this one from 1995:

https://groups.google.com/forum/#!topic/comp.arch.embedded/_fgqQEhJ7x8


George

[toc] | [prev] | [next] | [standalone]

#26388

On 2017-04-18, George Neuner <gneuner2@comcast.net> wrote:
> On Tue, 18 Apr 2017 12:57:46 -0500, Tim Wescott
><seemywebsite@myfooter.really> wrote:
>
>>How old is the thread that [kevinferg] didn't bother quoting, thus leaving
>>all of us with real newsreaders in the dark?
>
>
> I'm guessing it's this one from 1995:
>
> https://groups.google.com/forum/#!topic/comp.arch.embedded/_fgqQEhJ7x8

Yep.  He's apparently replying to a post by Charles Manning from 22
years ago.

Whatever...

-- 
Grant Edwards               grant.b.edwards        Yow! We have DIFFERENT
                                  at               amounts of HAIR --
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#26393

> Yep.  He's apparently replying to a post by Charles Manning from 22
> years ago.
> 

In 1995 Cfront was a viable C++ complier.

[toc] | [prev] | [next] | [standalone]

#26406

Le 18/04/2017 à 18:50, kevinferg@gmail.com a écrit :
>  C++ has a much higher level of abstraction than ANSI-C
Please don't speak about this kind of assumption. You are a programmer ?

Habib.

[toc] | [prev] | [next] | [standalone]

#26429

On Mon, 24 Apr 2017 22:18:05 +0200, habib <h.bouazizviallet@free.fr>
wrote:

>Le 18/04/2017 à 18:50, kevinferg@gmail.com a écrit :
>>  C++ has a much higher level of abstraction than ANSI-C
>Please don't speak about this kind of assumption. You are a programmer ?
>
>Habib.

I think the real question is: are you a programmer?


Abstraction ability is *not* synonomous with power.  Assembler is able
to do anything that any high(er) level language can do - but would you
honestly try to claim that assembler and C have comparable abstraction
capabilities?

C++ is not more powerful than C, but C++ absolutely *does* have
greater abstraction ability - in general, a C version of a C++ program
will be larger, more complex, and require more programmer effort to
write and maintain.

It is a fact that the first C++ implementations compiled to C as an
intermediate step ... however, modern C++ compilers no longer do this
because the semantic differences between C++ and C now are so great
that translation to C negatively impacts performance of C++ code.

George

[toc] | [prev] | [next] | [standalone]

#26437

On Tue, 25 Apr 2017 16:07:29 -0400, George Neuner
<gneuner2@comcast.net> wrote:

>It is a fact that the first C++ implementations compiled to C as an
>intermediate step ... however, modern C++ compilers no longer do this
>because the semantic differences between C++ and C now are so great
>that translation to C negatively impacts performance of C++ code.


cfront broke down when they tried to add exceptions to C++.  Doing
exceptions without at least a bit of compiler support is just too
difficult.  Which is another way of saying it introduced unacceptable
overhead.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch.embedded

csiph-web