A concept of a new PL for embedded applications

[Hutorny]

I would like to discuss with you my ideas on a new programming language for embedded applications, denoted further as e#. Here I post only the core concept. More details can be found on this link

The core concept
e# is a tool language that should be suitable for all kind of embedded-related development activities, starting from defining the device architecture and its instruction set, documenting device specifics and finishing with programming the device with a developed application. Instead of allowing the developer to write an arbitrary language constructions and pushing the compiler to made an executable out of it, e# should let a developer (a device vendor) to express the device resources, capabilities and constraints in the language terms. These capabilities and constraints than are applied to the application sources, simulation model and executable image. If any of the constraints are violated the e# builder would produce error, either compilation, simulation or code generation time.
It should retain major assembler’s capability to express application’s logic in terms of processors instructions, where each statement is translated into known number of know instruction of a given CPU/MCU.
The language should allow writing generic libraries for a given architecture operating on common architecture-wide facilities expressed in terms of a lowest subset of ‘abstract device instructions’ declared for the architecture, which then, at application level, are implemented/instantiated for a given MCU.
Shortly e# can be defined as a compilable code generator – at first sources are compiled then they are executed and, as a result of this execution, application code is generated. Compilation should not generate any target device code, it should only verify syntax and generate instructions on how to generate target device code. e# definitely is a high level programming language, however, applications written in it should still be able to use features of a low-level programming language, such as access to all available device resources.
It is believed that the concept could be applicable to RISC, CISC and VLIW architectures, although, the latter one will require more efforts on describing the device.

 

[Papabravo]

There are two groups of developers. Those who make the best use of the available tools and produce truly amazing results are the first kind. Those who engage in a perpetual search for something better are the second kind. We need both, and I hope your efforts are successful.

Frankly though, from my standpoint, it looks like a solution in search of a problem. It's going to be a great deal of work for a vanishingly small payoff.

 

[Hutorny]

Thanks for your words.
Recently I have failed to implement my design due to limitations in three HLL compilers I tried. That was the last thing which has pushed me in this direction.
I would be happier using a well established development tool that finds all of my "stupid errors", but no luck so far finding such a tool.

 

[Nigel Goodwin]

Thanks for your words.
Recently I have failed to implement my design due to limitations in three HLL compilers I tried. That was the last thing which has pushed me in this direction.
I would be happier using a well established development tool that finds all of my "stupid errors", but no luck so far finding such a tool.

What problems were you having? - if you are unable to write high level code without making "stupid errors"?, I fail to see how you hope to write a compiler?.

 

[Hutorny]

What problems were you having? - if you are unable to write high level code with making "stupid errors"?, I fail to see how you hope to write a compiler?.

Sorry for the misleading post.
HLL copilers has failed to generate code for valid syntax.
I can implement my design in assembelr, but this is less error prone and leave higher chances to make a stupid error.

 

[Nigel Goodwin]

HLL copilers has failed to generate code for valid syntax.

This sounds highly doubtful?, have you an example of code that doesn't work?.

 

[Hutorny]

This sounds highly doubtful?, have you an example of code that doesn't work?.

Dear Nigel,
I have already contacted tool vendors regarding my all problems and I was not satisfied with the answer.

Nevertheless, this post is not about a particular problem I have with a particular development tool and I do not want this discussion going that way.

Thanks for your kindness.

 

[Nigel Goodwin]

Dear Nigel,
I have already contacted tool vendors regarding my all problems and I was not satisfied with the answer.

Nevertheless, this post is not about a particular problem I have with a particular development tool and I do not want this discussion going that way.

Well the entire thread seems pretty pointless then?.

From what I can see your 'complaint' is that the compilers do what you 'tell them', and not what you 'wanted' them to do?.

So, presumably, you're wanting to write a 'magical' compiler that does what you 'want' and not what you 'tell it'? - I don't see how that can be possible, at least not that will produce any worthwhile code?.

 

[philba]

actually, there are several PIC compilers that fail to generate code for ANSI C valid constructs. the Knudson compiler for the 14 bit cores (cc5x) will give up on certain sequences. it tells you and you simplify or break into multiple statements. annoying but it does generate good code and the source is still valid ANSI

Frankly, it's a minor annoyance and not worth moving to a new language over. perhaps for experience with the tools is called for?

 

[Hero999]

Isn't there any port of the GCC for an embedded system?

 

[Nigel Goodwin]

actually, there are several PIC compilers that fail to generate code for ANSI C valid constructs. the Knudson compiler for the 14 bit cores (cc5x) will give up on certain sequences. it tells you and you simplify or break into multiple statements. annoying but it does generate good code and the source is still valid ANSI

Why would a PIC C compiler need to be ANSI compatible?, it doesn't really have the hardware - C was written for writing operating systems on main frames and mini computers, it's really a 'bodge' applying it to a poor little PIC with 'RAM' only in double figures.

 

[Papabravo]

To persevere, adapt, and overcome problems with existing tools seems a far more profitable enterprise than mucking about with new paradigms. I doubt that you could even establish metrics which would demonstrate the value of your constructs.

That does not mean that you shouldn't try whatever your heart desires, just realize there is a great deal of inertia that must be overcome. If the benefits of your proposal were self evident then I might be able to muster a bit more enthusiasm.

I think to make your argument, you need to document and explain the three examples that drove you to this proposal.

 

[philba]

Why would a PIC C compiler need to be ANSI compatible?, it doesn't really have the hardware - C was written for writing operating systems on main frames and mini computers, it's really a 'bodge' applying it to a poor little PIC with 'RAM' only in double figures.

clearly a PIC compiler can't be 100% ANSI C but but valid code sequences can be. The closer the better. the point is that it's real C. I have a number of libraries that I have moved to different processors. The effort was pretty small. Portable code is a huge benefit. Not sure why you care as you are a MASM uber alles kind of guy.

The earliest C compiler was targeted at the PDP-11 instruction set which was only slightly richer than the PIC. I can knock off a quick program in C a lot faster than in MASM. Sure it's not as efficient but there is enough control for me to do what I want. I don't see much point in arguing this point with you - I doubt you would ever change your mind.

 

[Hutorny]

Well the entire thread seems pretty pointless then?.

Well, if you turn it this way...

I have designed my application divided on loosely coupled objects communicating via interfaces.
And I have failed to implement interfaces because SDCC, PICC, and mikroPascal for PIC14 family do not generate proper code to work with function pointers.

But again, this problem is not the reason for my post. I have started thinking about this concept since 2003 and periodically was looking what new comes to this field.

From what I can see your 'complaint' is that the compilers do what you 'tell them', and not what you 'wanted' them to do?.
So, presumably, you're wanting to write a 'magical' compiler that does what you 'want' and not what you 'tell it'? - I don't see how that can be possible, at least not that will produce any worthwhile code?.

I would say my intent is just the opposite.
I want a strict syntax compiler that would do only what I said to do - at instruction level if I want to say at instruction level, or at higher level, if I (or some one else) have designed and implented that higher level for a particular architecture, platform or device.

Talking about HLL languages in general, I have expresses my opinion in post ASM vs HLL.

 

[Hutorny]

To persevere, adapt, and overcome problems with existing tools seems a far more profitable enterprise than mucking about with new paradigms. I doubt that you could even establish metrics which would demonstrate the value of your constructs.

Thanks for reminding about metrics, this is an important aspect whic I did not think about yet.

That does not mean that you shouldn't try whatever your heart desires, just realize there is a great deal of inertia that must be overcome. If the benefits of your proposal were self evident then I might be able to muster a bit more enthusiasm.

I expected inertia and started this discussions to see if I have expressed my idea essentially clear to be understood and accepted by other people.

I think to make your argument, you need to document and explain the three examples that drove you to this proposal.

Ok, I will.

 

[Nigel Goodwin]

I have designed my application divided on loosely coupled objects communicating via interfaces.
And I have failed to implement interfaces because SDCC, PICC, and mikroPascal for PIC14 family do not generate proper code to work with function pointers.

This has always been my point about assembler vs. HLL, and this proves it again - because you don't write assembler you have no clue as to the hardware you're using, and the limitations that incurs.

Basically you're writing code to run on a main frame, and expecting a tiny little chip with puny amounts of RAM to be able to run it.

I suggest you try studying the hardware and the datasheets, pay particular attention to the number of GPR's available, and even more so to the size of the stack available.

You're simply trying to write totally inappropriate code, due to a lack of understanding of your target system.

BTW, I don't write C (and have no intention of ever doing so), but I have written a LOT of Pascal - and the PIC architecture isn't very good for that either, nor is it good for Forth, all three of those languages are very 'stack dependent'.

 

[Hutorny]

This has always been my point about assembler vs. HLL, and this proves it again - because you don't write assembler you have no clue as to the hardware you're using, and the limitations that incurs.

Agree. I also prefer assembler. Indeed, when starting this project I have considered HLLs and the reason for this are the following.
I am developing the application iteratively with some time gaps between iterations, thus when I am starting new iteration I usually do not remember agreements I have established on inter-object communication and assumptions I made. I expected that HLL with a better syntax check would allow better interface definition. Another reason - I suspect that my application may eventually exceed capabilities of PIC14 family and I will need to move it on PIC16. They are close enough but not identical.
Also event within the same family there are certain differences that may make application malfunctioning. For example, a control bit happens to be in a different register. Unfortunatelly, assemblers (or at least assemblers I know) do not detect these kind of nuances. I think they could but I doubt they would.

Basically you're writing code to run on a main frame, and expecting a tiny little chip with puny amounts of RAM to be able to run it.

I suggest you try studying the hardware and the datasheets, pay particular attention to the number of GPR's available, and even more so to the size of the stack available.

That's an easy way.

You're simply trying to write totally inappropriate code, due to a lack of understanding of your target system.

Did I give you a reason to think so?

BTW, I don't write C (and have no intention of ever doing so), but I have written a LOT of Pascal - and the PIC architecture isn't very good for that either, nor is it good for Forth, all three of those languages are very 'stack dependent'.

PIC architecture and tiny devices are not very good for any HLL, but it is not a reason to have the development tool invented by our grandma's

 

[Nigel Goodwin]

Did I give you a reason to think so?

Yes you did!.

not generate proper code to work with function pointers

 

[Hutorny]

Yes you did!.

Is there anything I can do to make you changing your mind?

 

[eblc1388]

For example, a control bit happens to be in a different register. Unfortunatelly, assemblers (or at least assemblers I know) do not detect these kind of nuances. I think they could but I doubt they would.

I doubt they should.

When one uses the name of a control bit to refer to it, and use the proper "include" file during assembly, why should the assembler complaints of any errors?