Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #26385
| 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> |
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
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