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


Groups > comp.arch.embedded > #26385

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

From Dimiter_Popoff <dp@tgi-sci.com>
Newsgroups comp.arch.embedded
Subject Re: Wanted: C or C++ compiler for Intel 8031/8051 ***
Date 2017-04-18 20:43 +0300
Organization TGI
Message-ID <od5j1a$efd$1@dont-email.me> (permalink)
References <5pPAkTx.bobcastorf@delphi.com>#1/1> <70885e4e-2aec-4fa5-86b5-29beaf3c4681@googlegroups.com>

Show all headers | View raw


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/

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web