Re: Adapting an Ada compiler to generate 8051 code (Again?! ;-)

[Shark8 <onewingedshark@gmail.com>]

On Tuesday, March 30, 2021 at 3:04:43 AM UTC-6, mockturtle wrote:
> Dear.all, 
> for a project related to a possible start-up, we need to program a Flash controller that has a 8051 core (as many other controllers). I would like using Ada for that, but I discovered (also by browsing c.l.a.) that there is no Ada compiler producing 8051 code. 
> 
> I am considering involving some university colleagues of mine to start a project aimed to having an Ada compiler for 8051, possibly leveraging some existing compiler. According to some post read here, I understand that it is not totally impossible, if we are willing to accept some limitations. 
> 
> I did not study (yet) in detail the 8051, but as I understand it is a small 8-bit processor, with flash memory for code and data and a small amount of RAM onboard (but maybe this depends on the specific controller). My knowledge about compilers is superficial, but I guess we should give up to some Ada features like 
> 
> * Multitasking (maybe only non preemptive policy, single priority, no dynamic task allocation? Kind of coroutines...)
This depends. Dynamic multitasking would likely never work, but a statically-set multitasking should be doable.
While I wouldn't recommend using GNAT for targeting the 8051, this thesis lays out a lot of stuff on proving schedulability and WCET-proofs.
https://openresearch-repository.anu.edu.au/bitstream/1885/112723/1/Bernardi%20P%20Thesis%202017.pdf

> * Dynamic memory allocation
Maybe.
Take a look at Ada's storage-pools here and you might be able to use some dynamic-memory, provided it goes through a custom allocator. (This is actually a really good exercise: make an pool implemented as an array [indexed 0..14] w/ an access type that is a 4-bit integer, using 15 as the null-value. Doing this will help you to understand access types a lot better.)

> * Exception raising, but not handling, an exception would stop the execution (I guess having an exception inside a microcontroller is not a nice idea... This sounds like a job for Spark to be sure that no exception will happen)
Are you going to implement a SPARK prover, or prove the source separately and then feed it into the compiler?

> * OOP? Some of that can be retained?
There's an excellent couple of paper on optimizing OOP:
https://scholarworks.umass.edu/cgi/viewcontent.cgi?article=1008&context=cs_faculty_pubs & ftp://trout.cs.washington.edu/tr/1996/06/UW-CSE-96-06-02.pdf
The end-result is that a LOT of the dynamic-dispatch can be optimized to statically-known calls, especially in the presence of whole-program optimization.

> * Run-time check of contracts (maybe can be kept active during development and debugging)
I would recommend that they be kept on at all times, unless (a) actual benchmarking shows them to be a problem, and (b) they can be proven unnecessary.

> Considering the kind of software usually run inside a micro-controller, these limitations do not sound too severe. We would retain all the "syntactic features" of Ada like strong typing, packages, named parameters and so on... that are a strong help in writing correct software. Also, with the limitations above a 8051 Ada code most probably would be also a Spark code.
Or, alternatively, you could have the back-end signal what it can and cannot support, erroring out with a good error-message if an unsupported construct is submitted.
(Just like the Ada-compiler can do if something is requested beyond its capabilities, like a custom integer-range suprsetting the system's own word-range.)

> I have some knowledge about compilers, but not so deep to understand the difficulties of this project and I would like to ask you 
> 
> 1. The most challenging points that you see in such a project, also if I forgot something in the list of "feature to be given up"
Ada isn't a small language, but it's also not a large language compared to linguistics.
The most challenging part I think, would be getting buy-in and effort in the project.
> 2. Some compiler we can start from
Byron is freely available, and MIT-licensed... but I only have up to the parser done, IIRC.
One thing that I am shooting for with Byron is having an easily interchangeable backend (code-generation), though with FORTH being the sort of default output. [To aid in bootstrapping the compiler, since FORTH is easy to port. The idea being compile to FORTH, run the FORTH on your new machine, then (if needed) write your native backend and recompile with that: Bam! a new native-code compiler.]
> 3. An estimate of the effort in person-month (you wish...), considering a skilled but inexperienced programmer (like a skilled university student) 
I don't know.
It's sometimes easier when you have collaborators, and it's sometimes that collaborators 'get in the way'.