Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #27185
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Engineering degree for embedded systems |
| Date | 2017-08-25 09:51 -0400 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <onpa18$1m9j$1@gioia.aioe.org> (permalink) |
| References | (16 earlier) <on3gra$84q$1@dont-email.me> <on41ti$1ifm$1@gioia.aioe.org> <on47kq$b3h$1@dont-email.me> <on4fff$824$1@gioia.aioe.org> <on6n98$g16$1@dont-email.me> |
On 2017-08-18 8:45 AM, David Brown wrote:
> On 17/08/17 18:15, Walter Banks wrote:
>> On 2017-08-17 10:06 AM, David Brown wrote:
>>> On 17/08/17 14:24, Walter Banks wrote:
>>>
>>
>> To be really clear this was a TR and never expected to be added to
>> the C standards at the time.
>
> I assume that it was hoped to become an addition to the C standards,
> or at least a basis and inspiration for such additions - otherwise
> what was the point? I would be quite happy with the idea of
> "supplementary" standards to go along with the main C standards, to
> add features or to provide a common set of implementation-dependent
> features. For example, Posix adds a number of standard library
> functions, and gives guarantees about the size and form of integers -
> thus people can write code that is portable to Posix without imposing
> requirements on compilers for an 8051. A similar additional standard
> giving features for embedded developers, but without imposing
> requirements on PC programmers, would make sense.
>
>>
>> In the current environment I would like to see the C standards
>> moved forward to support the emerging ISA's. There are many
>> current applications that need additions to the language to
>> describe effective solutions to some problems. Ad-hoc additions
>> prevent the very thing that C is promoted for, that is
>> portability.
>
> C is intended to support two significantly different types of code.
> One is portable code that can run on a wide range of systems. The
> other is system-specific code that is targeted at a very small number
> of systems. If you are writing code that depends on features of a
> particular ISA, then you should be using target-specific or
> implementation-dependent features.
>
> If a new feature is useful across a range of targets, then sometimes
> a middle ground would make more sense. The C standards today have
> that in the form of optional features. For example, most targets
> support nice 8-bit, 16-bit, 32-bit and 64-bit integers with two's
> complement arithmetic. But some targets do not support them. So C99
> and C11 give standard names and definitions of these types, but make
> them optional. This works well for features that many targets can
> support, and many people would have use of.
>
> For features that are useful on only a small number of ISA's, they
> should not be in the main C standards at all - a supplementary
> standard would make more sense. Yes, that would mean fragmenting the
> C world somewhat - but I think it would still be a better
> compromise.
At the time 18037 was written there was a consensus that C should have a
core set of common features and additional standards written to support
specific additional application areas. The working title for 18037 was
"C standards for Embedded Systems". Common core features turned out in
practice to be very difficult to agree on and it was essentially abandoned.
The standard names was the way tying more diverse users together. In
general have worked well to support the types of embedded work that I do
without staying too far from the C language.
>>
>> So many of the development tools still are restricted by the
>> technology limits of development environments of 40 years ago.
>
> It is the price of backwards compatibility. Like most C programmers,
> I have my own ideas of what is "old cruft" that could be removed from
> C standards without harm to current users. And like most C
> programmers, my ideas about what is "old cruft" will include things
> that some other C programmers still use to this day.
The argument is more about development tools than language. Our tools
for example support both compiling to objects and linking as well as
absolute code compiling to an executable. We have supported both for a
long time. Our customers are split over the approach they use for
application development.
We have always compiled directly to machine code in our tools also not a
language specific issue. Development platforms once had limited
resources that were overcome with linking and post assembly translation.
Those restrictions don't apply any more.
The effects of old code generation technology is even more manifest than
that. Linking has become a lot smarter on terms of code generation but
it is a lot more computationally expensive than running a compiler
strategy pass to analyze the data and control flow of and application.
This information can give a compiler an overall plan to create code for
the application this time.
>>
>> The named address space has often been used to support diverse
>> forms of memory. To use your example x = 1; The choice where x is
>> located and how it is accessed is made where it is declared. How it
>> is handled after that is made by the compiler. The assumption is
>> that the code is written with functional intent.
>>
>
> Yes, that is the nice thing about named address spaces here.
>
>> As valid as the SPI conflict is it is a strawman in practice. C is
>> filled with undefined and ambiguous cases and this type of
>> potential problem in practice is very rare.
>
> I don't agree.
>
> I am /not/ saying the benefits are not worth the costs here - I am
> saying this needs to be considered very, very carefully, and
> features needed to be viewed in the context of the effects they can
> cause here. There are no /right/ answers - but calling it "a strawman
> in practice" is very much the /wrong/ answer. Problems that occur
> very rarely are the worst kind of problems.
>
I essentially stand behind my comments. Problems of moving variable
access methods using named address space have had few problems in practice.
>
> That is a very different kind of programming from the current
> mainstream, and it is questionably as to whether C is a sensible
> choice of language for such systems. But okay, let's continue...
Why, I have no real conflict with the historical C and generally have no
reason to want to impact old functionality. My approach is similar to
the K&R argument declaration changes. Add new syntax support both. 20
years later the marketplace will sort out which is used.
>
>> In the two decades since this work was initially done things have
>> changed considerably from consumer products that distributed an
>> application over 3 or 4 processors. (after initially prototyping on
>> a single processor). In these processor usage was almost always
>> manually allocation using geographical centers of reference.
>>
>> This has evolved to compiler analysis that automate this whole
>> process over many many processors.
>>
>
> I assume you are not talking about multi-threaded code working on an
> SMP system - that is already possible in C, especially with C11
> features like threading, atomic access, and thread-local data. (Of
> course more features might be useful, and just because it is possible
> does not mean programmers get things right.)
>
> You are talking about MPPA ("Multi purpose processor array") where
> you have many small cores with local memory distributed around a
> chip, with communication channels between the nodes.
>
That is a close enough description. C has been filled with ad-hoc
separate memory spaces. Thread local data you just mentioned, dsp
separate memory, historical real separate spaces for small embedded
systems, paging and protected memory. Don't discard these but formalize
there declaration and use. Do it in a way that can incorporate
functionally what has been done and don't do anything to impede the
continued use of what is there now.
In a similar way look at the current approach to multiprocessors
support. How different are threads to multiple execution units. Why
shouldn't multiprocessors be managed in similar ways that memory space
is currently managed and allocated now at least allowing for these to be
machine instead of manually optimized? Finally why shouldn't generic
approaches be formalized so the tools aren't restricting application
development?
By arguments for doing this in the C context are two. First the real
impact on the language is small, all are additions not changes and have
no impact on existing code bases. Second C is a living language and has
lasted as long as it has because standards for the language are there to
codify current practices.
w..
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Engineering degree for embedded systems "hogwarts" <122707@EmbeddedRelated> - 2017-07-27 07:35 -0500
Re: Engineering degree for embedded systems Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2017-07-27 15:25 +0200
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-07-30 12:05 -0400
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-07-30 19:05 +0100
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-01 08:55 -0400
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-01 14:23 +0100
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-03 11:03 -0400
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-06 10:35 +0100
Re: Engineering degree for embedded systems John Devereux <john@devereux.me.uk> - 2017-08-06 14:40 +0100
Re: Engineering degree for embedded systems rickman <gnuarm@gmail.com> - 2017-08-06 12:51 -0400
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-06 20:13 +0100
Re: Engineering degree for embedded systems rickman <gnuarm@gmail.com> - 2017-08-06 19:21 -0400
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-07 12:40 -0400
Re: Engineering degree for embedded systems rickman <gnuarm@gmail.com> - 2017-08-07 15:18 -0400
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-07 15:27 -0400
Re: Engineering degree for embedded systems rickman <gnuarm@gmail.com> - 2017-08-07 16:47 -0400
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-07 17:30 -0400
Re: Engineering degree for embedded systems rickman <gnuarm@gmail.com> - 2017-08-07 18:35 -0400
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-07 18:56 -0400
Re: Engineering degree for embedded systems rickman <gnuarm@gmail.com> - 2017-08-07 19:02 -0400
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-07 19:08 -0400
Re: Engineering degree for embedded systems Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-08-08 01:30 +0200
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-07 19:32 -0400
Re: Engineering degree for embedded systems rickman <gnuarm@gmail.com> - 2017-08-07 19:53 -0400
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-07 20:02 -0400
Re: Engineering degree for embedded systems stephen@mpeforth.com (Stephen Pelc) - 2017-08-07 23:49 +0000
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-07 20:07 -0400
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-08 08:00 +0100
Re: Engineering degree for embedded systems George Neuner <gneuner2@comcast.net> - 2017-08-07 01:21 -0400
Re: Engineering degree for embedded systems upsidedown@downunder.com - 2017-08-06 17:15 +0300
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-06 20:21 +0100
Re: Engineering degree for embedded systems upsidedown@downunder.com - 2017-08-07 10:35 +0300
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-07 12:54 +0200
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-07 12:34 +0200
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-07 12:43 -0400
Re: Engineering degree for embedded systems rickman <gnuarm@gmail.com> - 2017-08-06 12:50 -0400
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-07 12:36 -0400
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-07 18:40 +0100
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-08 10:23 +0200
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-08 09:46 +0100
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-08 11:26 +0200
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-08 11:09 +0100
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-08 12:56 +0200
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-08 15:56 +0100
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-08 17:11 +0200
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-08 16:33 +0100
Re: Engineering degree for embedded systems upsidedown@downunder.com - 2017-08-08 21:07 +0300
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-09 10:03 +0200
Re: Engineering degree for embedded systems upsidedown@downunder.com - 2017-08-10 14:30 +0300
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-10 15:11 +0200
Re: Engineering degree for embedded systems Walter Banks <walter@bytecraft.com> - 2017-08-16 18:39 -0400
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-17 09:37 +0200
Re: Engineering degree for embedded systems Walter Banks <walter@bytecraft.com> - 2017-08-17 08:24 -0400
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-17 16:06 +0200
Re: Engineering degree for embedded systems Walter Banks <walter@bytecraft.com> - 2017-08-17 12:15 -0400
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-18 14:45 +0200
Re: Engineering degree for embedded systems Walter Banks <walter@bytecraft.com> - 2017-08-25 09:51 -0400
Re: Engineering degree for embedded systems Les Cargill <lcargill99@comcast.com> - 2017-08-01 20:46 -0500
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-02 09:30 +0200
Re: Engineering degree for embedded systems Les Cargill <lcargill99@comcast.com> - 2017-08-05 15:11 -0500
Re: Engineering degree for embedded systems Paul Rubin <no.email@nospam.invalid> - 2017-08-08 00:22 -0700
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-08 08:36 +0100
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-08 12:37 +0200
Re: Engineering degree for embedded systems "tim..." <tims_new_home@yahoo.com> - 2017-07-27 17:46 +0100
Re: Engineering degree for embedded systems Grant Edwards <invalid@invalid.invalid> - 2017-07-27 16:54 +0000
Re: Engineering degree for embedded systems "tim..." <tims_new_home@yahoo.com> - 2017-07-27 19:57 +0100
Re: Engineering degree for embedded systems Frank Miles <fpm@u.washington.edu> - 2017-07-27 16:58 +0000
Re: Engineering degree for embedded systems Theo Markettos <theom+news@chiark.greenend.org.uk> - 2017-07-28 00:43 +0100
Re: Engineering degree for embedded systems jim.brakefield@ieee.org - 2017-07-30 15:26 -0700
Re: Engineering degree for embedded systems Chris <xxx.syseng.yyy@gfsys.co.uk> - 2017-07-27 23:45 +0000
Re: Engineering degree for embedded systems Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-08-03 19:50 +0200
Re: Engineering degree for embedded systems Les Cargill <lcargill99@comcast.com> - 2017-08-05 15:20 -0500
Re: Engineering degree for embedded systems upsidedown@downunder.com - 2017-08-06 09:17 +0300
Re: Engineering degree for embedded systems "tim..." <tims_new_home@yahoo.com> - 2017-08-06 10:12 +0100
Re: Engineering degree for embedded systems upsidedown@downunder.com - 2017-08-06 13:19 +0300
Re: Engineering degree for embedded systems Les Cargill <lcargill99@comcast.com> - 2017-08-06 09:59 -0500
Re: Engineering degree for embedded systems "tim..." <tims_new_home@yahoo.com> - 2017-08-06 18:06 +0100
Re: Engineering degree for embedded systems rickman <gnuarm@gmail.com> - 2017-08-06 21:31 -0400
Re: Engineering degree for embedded systems "tim..." <tims_new_home@yahoo.com> - 2017-08-07 09:32 +0100
Re: Engineering degree for embedded systems Les Cargill <lcargill99@comcast.com> - 2017-08-06 09:53 -0500
Re: Engineering degree for embedded systems upsidedown@downunder.com - 2017-08-07 10:59 +0300
Re: Engineering degree for embedded systems Les Cargill <lcargill99@comcast.com> - 2017-08-07 20:09 -0500
Re: Engineering degree for embedded systems upsidedown@downunder.com - 2017-08-08 21:31 +0300
Re: Engineering degree for embedded systems Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2017-08-21 11:28 +0200
csiph-web