A microcontroller-centric, target-neutral programming language

Hi Paul,

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

Pete Gray schrieb in im Newsbeitrag: snipped-for-privacy@comp.compilers...

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 Ro> I'm about to embark on a project to produce a microcontroller-centric,

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.

Hi Paul,

What is this supposed to be ? Something like BASIC (see BASCOM

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

Pete Gray schrieb in im Newsbeitrag:

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

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

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

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.

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

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.

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

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?

TenDRA: This is actually a compiler that generates TDF (Ten15 Distribution Format). See

ANDF: Architecture Neutral Distribution Format, OSF effort based on TenDRA technology,

SUIF: Stanford University Intermediate Format,

RIF: Riverside Intermediate Format, based on C--, which is one I forgot,

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).

Regards,

-=Dave

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.

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

-jg

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:

Tanya

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

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

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

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.

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 visi.com the hors d'oeuvres.

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,