A microcontroller-centric, target-neutral programming language

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I'm about to embark on a project to produce a microcontroller-centric,
target-neutral programming language.
I'd like to hear views regarding the pros and cons of Industry or Academic
sponsorship versus the Open Source approach.

Thanks in advance,
-Pete.
snipped-for-privacy@ieee.org

Re: A microcontroller-centric, target-neutral programming language
Hi Paul,

Quoted text here. Click to load it

What is this supposed to be ?
Something like BASIC (see BASCOM 8051/AVR)

Or another C/EC++ ?

If you look at embedded applications in the 8/16 bit arena, even 32 bit
(like PPC, 68k)
You will allways see controller and derivative depended modules. This is
simply unavoidable when dealing with the diversity of microcontroller
applications, moreso looking at possible variations of hardware
configuration.

Simply consider the hardware setup and startup code for a Motorola PPC or
Infineon's 16 bit XC16x V2 core series or the 32 bit TriCore.
There is no such thing as hardware independency.

How are the very complex peripherals (TPU, CAPCOM, CAN, etc...) going to be
utilized efficiently, if not hardware dependend ?

Could you explain who will use it and what applications shall be designed
with it ?

Just curious.

with kind regards

/jan


snipped-for-privacy@comp.compilers...
Quoted text here. Click to load it



Re: A microcontroller-centric, target-neutral programming language

I think such a language is called 'C'.  gcc has been ported to a very large
set of microcontrollers, most at the higher end of the performance range.
It has also been ported to some at the low end, eg. HC11, and there are
a number of other open source compilers for various low end micros.
I personally would like to see someone come up with the really good, and easily
retargetted, open source, C compiler for the low end, rather than create yet
another
language.

Dave Rooney

Pete Gray wrote:
Quoted text here. Click to load it


Re: A microcontroller-centric, target-neutral programming language
Quoted text here. Click to load it

Why is this a good idea?  Surely abstracting machine word lengths,
byte ordering and access to onboard peripherals will only increase
execution times and executable code footprints?  Small, fast
executable code and microcontrollers go hand in hand.

Re: A microcontroller-centric, target-neutral programming language
Hi Paul,

Quoted text here. Click to load it

What is this supposed to be ?  Something like BASIC (see BASCOM
8051/AVR)

Or another C/EC++ ?

If you look at embedded applications in the 8/16 bit arena, even 32
bit (like PPC, 68k) You will allways see controller and derivative
depended modules. This is simply unavoidable when dealing with the
diversity of microcontroller applications, moreso looking at possible
variations of hardware configuration.

Simply consider the hardware setup and startup code for a Motorola PPC
or Infineon's 16 bit XC16x V2 core series or the 32 bit TriCore.
There is no such thing as hardware independency.

How are the very complex peripherals (TPU, CAPCOM, CAN, etc...) going
to be utilized efficiently, if not hardware dependend ?

Could you explain who will use it and what applications shall be
designed with it ?

Just curious.

with kind regards

/jan

Quoted text here. Click to load it

Re: A microcontroller-centric, target-neutral programming language

Quoted text here. Click to load it

Pete,
The key question here is not sponsored vs. open source but rather,
will anyone out there adapt his software process to your language?
There are maybe hundreds of brilliant languages out there with a
zero user base and you will need huge amounts of manpower to
save your language from going down the same road. Not that I
want to discourage you from your task, and I admit that replacing
the C language is a tempting challenge, but the new one needs
to offer some fantastic features to make that sluggish mass of
worldwide software development move.
A new better-than-C language surely must satisfy a number of
regularity requirements that make it
- easy to produce efficient sourcecode from other tools (e.g. state
charts, numeric analysis tools)
- easy to reverse engineer and prove correctness of certain parts
of a program
- easy to retrieve and let slip in meta information about a whole
project so as to make it fit into the larger picture of software
development

While you are in the process of designing the language you will face
the competition of hundreds of C++ developers who will force the
natural evolution of our current C-centered world along their lines.
If you are really serious about this development, I recommend you
try to mobilize a number of enthusiasts maybe over GNU or some other
board which allows free thinking about such radical and new
developments.

regards,
Mark
--
Mark Piffer
MCU and DSP programming & software design

Re: A microcontroller-centric, target-neutral programming language
Thanks to everyone for the feedback - both via direct email and through the
newsgroups.

Some more info (sorry, but I've been responding to individual emails, rather
than to the group - I don't have newsgroup access from my workplace) ...

Target-neutral in the sense that a generic p-code would be generated, as a
transient state between the high-level language and assembly language.
Target-neutral p-code (or as I refer to it, n-code) to target-specific
assembly code translators would then be created, as required, for each
target. Naturally, the n-code would need to contain enough detailed
information for the "n-code to assembly language translator" to be
effective.

The benefit being the logical and physical separation of the language and
compiler from the target. Adopting this scheme allows all targets to benefit
from enhancements to the language (and compiler) without the need for
target-specific compiler modifications. It removes the need for
target-specific ports of the compiler.

An additional (and significant) benefit to this design is that once a
suitable n-code scheme is adopted, compilers for "other" high-level
languages could be developed to generate n-code. The point here being that
when these new compilers are developed, they will already be able to support
targets for which "n-code to assembly language translators" have been
developed.

Having said all that, the focus of my question was meant to be "Open Source
versus Sponsorship" ... he said, trying to ensure the nature of the original
post isn't bypassed.

Regards,
-Pete

Re: A microcontroller-centric, target-neutral programming language
Umm, this "N-code" sound kind of like what belongs between the front and back
end of a compiler. You're just moving parts of the back-end to run in a
separate program.

It also sounds like what Microsoft .NET does (is this where the "n" in "N-code"
coes from?). .NET compilers compile to a "Common Intermediate Langyage". When
run on the host, this gets compiled by a "Just-in-time" compiler into native
code the first time it is run.


Re: A microcontroller-centric, target-neutral programming language

Quoted text here. Click to load it

Yup. This has been standard practice in compiler design for
many years.

Quoted text here. Click to load it

Most compilers do it that way already.  There's usually a front
end program that hides that fact from you.  IOW, running "cc"
will probably invoke three for four different programs: cpp,
cc1, cc2, cc3, etc.

Quoted text here. Click to load it

Sure.  If you want, you could design your intermediate code so
that it could be either interpreted or compiled into native
format.

--
Grant Edwards                   grante             Yow!  Why was I BORN?
                                  at              
We've slightly trimmed the long signature. Click to see the full one.
Re: A microcontroller-centric, target-neutral programming language
Quoted text here. Click to load it

I've never heard of these (although UNCOL rings a bell - a very tiny faint one
- or maybe I'm having a stroke). From the Unix world? Pre-Unix?

Re: A microcontroller-centric, target-neutral programming language

Quoted text here. Click to load it

TenDRA: This is actually a compiler that generates TDF (Ten15
Distribution Format).  See http://www.tendra.org/ and
http://www.mca-ltd.com/martin/Ten15/introduction.html

ANDF: Architecture Neutral Distribution Format, OSF effort based on
TenDRA technology, http://www.info.uni-karlsruhe.de/~andf /

SUIF: Stanford University Intermediate Format,
http://suif.stanford.edu /

RIF: Riverside Intermediate Format, based on C--, which is one I
forgot, http://www.cs.ucr.edu/~thpproj/RIF /

UNCOL: Universal Computer-Oriented Language.  I'm not sure this is
anything real, but it is the earliest reference I could find on the
subject (1950's).
http://homepage.ntlworld.com/michael.harley/uncol.html has some
interesting information.

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

Re: A microcontroller-centric, target-neutral programming language
Quoted text here. Click to load it

Interesting list.

<anip>
Quoted text here. Click to load it

 Have a look a .NET and there are many different language compilers
already
released for that.

 There is potential for CIL -> uC, and a first step of this could be a
'CIL allocater' that creates a map file of the resource that
particular CIL needs, in a uC sense.

 
Quoted text here. Click to load it

 Do they have to be mutually-exclusive ?
Open source is good, esp for research related areas, and .NET has a lot
of
activity.

-jg

Re: A microcontroller-centric, target-neutral programming language

Quoted text here. Click to load it

How does this differ from other compilers (gcc for example)?

Quoted text here. Click to load it

AFAIK, this is pretty much SOP for compilers these days.  It's
how gcc works.

Quoted text here. Click to load it

Yup.  That's why when you build gcc you can pick from a
half-dozen or more languages and a dozen or so target
architectures.

Quoted text here. Click to load it

I still maintain that "Open Source" and "Sponsorship" are not
mutually exclusive, and are, in fact, orthogonal concepts.

--
Grant Edwards                   grante             Yow!  I want the presidency
                                  at               so bad I can already taste
We've slightly trimmed the long signature. Click to see the full one.
Re: UNCOL again, was A microcontroller-centric, target-neutral
Quoted text here. Click to load it

This particular idea was invented in the 1950s under the name UNCOL.
The original UNCOL project failed, and similar attempts have failed
over and over in the past half-century, most recently as the ANDF
project.

The problem is that even with 50 years of work, we don't know how to
write an intermediate language that's simultaneously expressive enough
to capture an interesting set of source languages, while being
abstract enough to translate to efficient code for a wide range of
targets.

The usual trajectory of failure is that people start with a few
semantically similar source languages and architecturally similar
target architectures, and it works fine.  (Building a system that can
compile C, C++, Fortran, and Ada to 32 bit byte addressed micros that
use ASCII character codes isn't hard.  If that's what you need, use
GCC.)

They announce their results with wild enthusiasm.  Then as they try to
add more languages and more targets, the intermediate code becomes
increasingly encrusted with special-case hacks until it dies of heat
death and its proponents slink away.

So please be sure you have an intermediate representation that handles
C++, Scheme, and Cobol, and can be translated to Itanium, Burroughs A
series, and IBM S/390 (with EBCDIC characters).  If you can't, I
wouldn't bother.

Regards,
John Levine, snipped-for-privacy@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl , Sewer Commissioner
"More Wiener schnitzel, please", said Tom, revealingly.

Re: A microcontroller-centric, target-neutral programming language

Quoted text here. Click to load it

I've read some of the replies here.  Maybe it's better to
withhold comment until we know more about what "target neutral"
means here, the kinds of microcontrollers are being discussed
(does it exclude microprocessors, for example?), and the scope
and depth of the project.

Jon

Re: A microcontroller-centric, target-neutral programming language
Perhaps I'm misunderstanding this, but it seems like the GNU C compiler
already does this (it currently supports a number of platforms,
including the AVR  - see:
http://gcc.gnu.org/install/specific.html ).

Tanya


Re: A microcontroller-centric, target-neutral programming language
On Thu, 24 Jul 2003 15:48:12 +0930, Tanya Cumpston

Quoted text here. Click to load it

I don't think you are misunderstanding.  Many, many CILs have
been proposed and developed over the years.  In some cases, in
order to support multiple languages and a common back end so
that effort spent on opimizations would benefit all of the front
end languages.  In some cases, this is take further so that
multiple targets could all benefit from suddenly having lots of
front end languages ported, once the back end was done, too.  In
other cases, it was barely more than a convenience because
several executables operated in tandem and this intermediate
form was the way they communicated.

The big question is exactly what purposes are intended to be
served.  Is the intent more to support a virtual machine, like
the old Pascal P-code machine, so that most of the optimizations
have long since been done and the important information needed
for further optimzation will be very difficult to reverse out?
Or is the intent to provide enough information so that there is
still excellent opportunities for optimizing to a specific
target?

Often, it's hard to find the right line to draw.  Do too much
work before emitting the CIL and you seriously hamper the
competive results of the back end.  Do too little and you've
done little more than parse the input and too much work is then
placed on the back end to make retargeting any more practical
than just writing a new compiler.

I'd very much like to see a CIL design which permits quickly
writing a target-specific back end without much optimization (in
other words, includes many records which can be usefully
ignored) and yet still includes enough information to support
moving code across condition-boundary edges, topological loop +
conditional logic inversions, and competitive results for
targets which span the register gamut from SPARC register and
register windows to the PIC W-only register.  Sounds like a
project just defining such, but it would be interesting to see.

Jon


Site Timeline