From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.8 required=3.0 tests=BAYES_00,PLING_QUERY autolearn=no autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!news.szaf.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Adapting an Ada compiler to generate 8051 code (Again?! ;-) Date: Tue, 30 Mar 2021 13:40:51 +0300 Organization: Tidorum Ltd Message-ID: References: <41bc7a62-9c70-466d-b316-5fc74a3ee845n@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net aFZdKMAMA0RD2J8WuGfCMQanFrbAS8t0LLfsNjWlbMXSBe1yDr Cancel-Lock: sha1:9dcLPsZdfCe7Ss04n3aroEkcdFE= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 In-Reply-To: <41bc7a62-9c70-466d-b316-5fc74a3ee845n@googlegroups.com> Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:61680 List-Id: On 2021-03-30 12:04, mockturtle wrote: > Dear.all, > or 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 > cc.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 advise against that approach. The 8051 architecture is far too limited and quirky (and ancient) to waste such a major effort on. However, you might have a look at the HAC compiler. AIUI, it generates code for a virtual machine, and it might be easier to implement that virtual machine in 8051 code than it would be to generate 8051 code from the compiler. > 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). There are many, many variants of the "8051". What they mostly have in common is a small "internal" on-chip RAM of 128 or 256 octets, and an optional, larger, but still usually at most 64 KiO, "external" RAM that can also be on-chip in current variants. There is a separate code memory, usually mask-PROM or flash, also at most 64 KiO, with Harvard architecture (separate code and data address spaces). The internal and external RAM are also separate address spaces, with separate instructions for reading and writing internal vs external RAM. There is also a third type of memory, IIRC called "paged" RAM, but not often used today, I believe. While the variants all have a similar basic instruction set, there are extensions and variations also in the instruction set. For example, the basic 8051 has a single Data Pointer (DPTR) register, which is the only register (apart from the PC) that has 16 bits and can be used to address external RAM. The memcpy routine on such an 8051 is not simple, nor fast. Some 8051 variants have added one or several other DPTR registers and instructions to manage them. Finding out the actual properties of the "8051" in your flash controller is the first thing you should do. > 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...) The larger forms of the 8051 can certainly run multi-tasking kernels. I don't see why a Ravenscar kernel could not be implemented. However, a major limitation of the 8051 architecture is that the HW stack (call-return stack) can exist only in the 256-octet internal RAM. C compilers for the 8051 go to great lengths to reduce the amount of stack needed by a task. Real-time kernels for the 8051 sometimes resort to treating the entire stack of a task as a shared resource, spilling the whole stack into external RAM when the task is suspended or preempted, and filling it back from external to internal RAM when the task is resumed. > * Dynamic memory allocation Should not be a problem, in the external RAM. > * 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) You could take the approach used by GNAT in simple run-times: exceptions can be raised and handled by _local_ handlers, in the same subprogram or block, but cannot propagate up to outer scopes (whether statically or dynamically nested). Then raising a locally-handled exception can be compiled to a jump instruction, and raising a locally-unhandled exception becomes a jump or call to the last-chance handler (followed by program abort and restart). > * OOP? Some of that can be retained? You can keep as much of OOP as is consistent with your memory (code and data) and processing-time resources. However, the compiler may have to generate more 8051 instructions for eg. dispatching calls than it generates for a more powerful instruction set. > * Run-time check of contracts (maybe can be kept active during > development and debugging) Same as for OOP. I think you have two options: 1. Use HAC and implement the HAC VM in 8051 code, either in C or in assembler. 2. Pay for the AdaCore Ada-to-C compiler and use an 8051 C compiler as a back end. Because of the internal/external RAM architecture of the 8051, efficient C code usually needs additional annotations to tell the compiler that a certain variable should be stored in internal RAM, or in external RAM, or that a certain pointer always points to internal RAM or to external RAM, or might point to either one. This could be a problem for the Ada-to-C compiler approach, as you would want to write the annotations in the Ada source and have them passed through to the generated C source. There are some free 8051 C compilers (for example SDCC, Small Device C Compiler), but most professional programming for the 8051 uses commercial compilers such as the ARM/Keil compiler or the IAR compiler. You could try SDCC first, but if you get problems with eg. using too much internal RAM, the commercial compilers might help. I have often wished that there would be Ada compilers for more microcontrollers, but I understand why there aren't. An Ada-to-C compiler seems the most promising route.