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

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

[mockturtle]

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

*    Dynamic memory allocation

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

*   OOP?  Some of that can be retained?

*   Run-time check of contracts (maybe can be kept active during development and debugging)

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. 


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"
2. Some compiler we can start from
3. An estimate of the effort in person-month (you wish...), considering a skilled but inexperienced programmer (like a skilled university student) 
 
Thank you!

Riccardo

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

[Dmitry A. Kazakov]

On 2021-03-30 11:04, mockturtle wrote:

> 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 think the efforts would be better invested in recycling all existing 
8051 cores. Make the planet greener! (:-))

Honestly, there is little useful one could do in 64K. Remember what one 
famous thinker and epidemiologist said about 640K? [640K is 10 times 
more than 64K]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Niklas Holsti]

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.

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

[Luke A. Guest]

On 30/03/2021 10:04, 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.

All you need is one of the 8051 gcc or llvm ports, there are plenty of 
them. Then you need the gnat front end to port.

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

[Gautier write-only address]

On Tuesday, March 30, 2021 at 11:56:35 AM UTC+2, Dmitry A. Kazakov wrote:

> Honestly, there is little useful one could do in 64K. Remember what one 
> famous thinker and epidemiologist said about 640K? [640K is 10 times 
> more than 64K] 

Well it depends...

On one hand there will be never enough memory (and cores) for the famous thinker's operating system just to run idle.

On the other hand you had some decades ago computers with everything stuffed in 64KB. For instance: a 16KB ROM with an OS, a BASIC interpreter, I/O, floating-point computations, etc.; 48KB RAM including the video memory. You had cool games and even a multi-window word processor on such a machine...

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

[mockturtle]

On Tuesday, March 30, 2021 at 11:56:35 AM UTC+2, Dmitry A. Kazakov wrote:
> On 2021-03-30 11:04, mockturtle wrote: 
> 
> > 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 think the efforts would be better invested in recycling all existing 
> 8051 cores. Make the planet greener! (:-)) 

That could be a nice idea, just maybe a bit out of my reach :-)

> 
> Honestly, there is little useful one could do in 64K. Remember what one 
> famous thinker and epidemiologist said about 640K? [640K is 10 times 
> more than 64K

Well, old ZX Spectrum with its 48K RAM extension (I and my brother said when we extended the RAM: "What are we going to do with all this memory?" :-D ) used just 64K and you could do nice stuff.  The first release of Turbo Pascal (editor and compiler integrated) was a .COM, limited by design to 64K.

I agree that it is easier to work without this limitation, but also the job of a flash microcontroller is not very complex.

> 
> -- 
> Regards, 
> Dmitry A. Kazakov 
> http://www.dmitry-kazakov.de

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

[mockturtle]

Thank you for the detailed answer!  

Yes, I received an answer via e-mail pointing me to the HAC.  It could be a nice route to follow. Also the Ada-to-C + C compiler sounds like a promising route, maybe easier to expand to other controllers.   

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

[Dmitry A. Kazakov]

On 2021-03-30 13:27, mockturtle wrote:

> Well, old ZX Spectrum with its 48K RAM extension (I and my brother said when we extended the RAM: "What are we going to do with all this memory?" :-D ) used just 64K and you could do nice stuff.  The first release of Turbo Pascal (editor and compiler integrated) was a .COM, limited by design to 64K.

I remember the glorious time when 1K weighted 1kg (:-))

When I started, I and my pal worked together on a 256K machine in two 
time sharing terminal sessions. That was RSX-11M. These days almost 
every executable begins at 5-10M.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Björn Lundin]

Den 2021-03-30 kl. 11:04, skrev mockturtle:
> 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.

One way would be to turn around your problem.
Find out what micro controllers there are and has an Ada compiler.
Pick one that suits your requirements.
Or does the 8051 has something unique that you intend to make use of?

-- 
Björn

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

[Luke A. Guest]

On 30/03/2021 12:24, Luke A. Guest wrote:
> On 30/03/2021 10:04, 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.
> 
> All you need is one of the 8051 gcc or llvm ports, there are plenty of 
> them. Then you need the gnat front end to port.

Ah nuts! I was thinking about the 6502.

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

[Shark8]

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

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

[Paul Rubin]

mockturtle <framefritti@gmail.com> writes:
> 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).

Can you possibly avoid that?  There are many microcontrollers that GCC
has back ends for, so you could use GNAT.  E.g. I think GNAT for the AVR
is a thing.  Of course even at the low end, ARM is everywhere now, and
that is even easier.

Besides the approaches other people have mentioned, I don't know if
there are any really large obstacles to targeting GCC to the 8051, or to
some kind of VM that the 8051 can simulate, since you don't care about
performance.  If you do care about performance, you won't be using an
8051 in the first place ;-).

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

[Luke A. Guest]

On 30/03/2021 20:16, Paul Rubin wrote:

> Besides the approaches other people have mentioned, I don't know if
> there are any really large obstacles to targeting GCC to the 8051, or to

The biggest obstacles will be the severe lack of registers. But it's 
possible, lm78 for example.

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

[Paul Rubin]

"Luke A. Guest" <laguest@archeia.com> writes:
>> there are any really large obstacles to targeting GCC to the 8051
> The biggest obstacles will be the severe lack of registers. But it's
> possible, lm78 for example.

Do  you mean this?  https://www.ti.com/lit/gpn/lm78
I wasn't familiar with it.  It looks awful, a couple special purpose
registers and something like 19 bytes of ram (I didn't look closely).

Does gcc actually generate code for it?  I don't know whether gcc
targets any old-fashioned accumulator machines with no registers.  I
thought it did, but maybe not.  I do know lots of people use it for the
AVR8 / Aruino etc.

It hadn't occurred to me but yeah, maybe gcc is built more around
register architectures and sdcc works differently.  I haven't really
looked.

I know SWEET16 is a 16 bit virtual machine that Steve Wozniak
implemented on the 6502 in the original Apple II, to get higher code
density than 6502 asm code.  It had 16 registers.  Doing something like
that on an 8051 and targeting GCC to it sounds fairly plausible.  I
wouldn't be surprised if it's been done already.

Does a minimal Ada runtime (Ravenscar or whatever) make particular
demands that require much outside-the-compiler support?

Adacore Ada-to-C is proprietary?  Oh well.  I wonder if generating C
output from GCC intermediate code is terribly difficult.  

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

[Luke A. Guest]

On 30/03/2021 22:48, Paul Rubin wrote:
> "Luke A. Guest" <laguest@archeia.com> writes:
>>> there are any really large obstacles to targeting GCC to the 8051
>> The biggest obstacles will be the severe lack of registers. But it's
>> possible, lm78 for example.
> 
> Do  you mean this?  https://www.ti.com/lit/gpn/lm78

Probably, same as the name in gcc/config.

> I wasn't familiar with it.  It looks awful, a couple special purpose
> registers and something like 19 bytes of ram (I didn't look closely).

Yup, very basic. I spoke to the author over email, he said he 
virtualises registers in the rtl and then generates code for the tiny 
amount of regs. I was looking at z80 at the time.

> Does gcc actually generate code for it?  I don't know whether gcc

Yup, apparently.

> targets any old-fashioned accumulator machines with no registers.  I
> thought it did, but maybe not.  I do know lots of people use it for the
> AVR8 / Aruino etc.

AVR isn't really an accumulator arch, it's got 32 registers. Even the 
6502 has a port, but that uses the zero page as virtual registers. The 
Z80 cannot do that as it starts executing from address 0 iirc.

> It hadn't occurred to me but yeah, maybe gcc is built more around
> register architectures and sdcc works differently.  I haven't really
> looked.

sdcc is much much simpler, has to be for the architectures it supports. 
Much more ad hoc than GCC. GCC is based around flat memory architecture 
and "many registers," that's in quotes because, well x86 ffs.

> I know SWEET16 is a 16 bit virtual machine that Steve Wozniak
> implemented on the 6502 in the original Apple II, to get higher code
> density than 6502 asm code.  It had 16 registers.  Doing something like
> that on an 8051 and targeting GCC to it sounds fairly plausible.  I
> wouldn't be surprised if it's been done already.

Dunno.

> Does a minimal Ada runtime (Ravenscar or whatever) make particular
> demands that require much outside-the-compiler support?

Ravenscare is 2 tasks max, no?

> Adacore Ada-to-C is proprietary?  Oh well.  I wonder if generating C
> output from GCC intermediate code is terribly difficult.
> 

Only way to do Ada to C that I can think of is with llvm with the C 
backend. If that's still being worked on.

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

[Simon Wright]

"Luke A. Guest" <laguest@archeia.com> writes:

> On 30/03/2021 22:48, Paul Rubin wrote:

>> Does a minimal Ada runtime (Ravenscar or whatever) make particular
>> demands that require much outside-the-compiler support?
>
> Ravenscare is 2 tasks max, no?

The limit on the number of tasks is the amount of RAM each task needs
for stack.

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

[Niklas Holsti]

On 2021-03-31 0:28, Luke A. Guest wrote:
> On 30/03/2021 20:16, Paul Rubin wrote:
> 
>> Besides the approaches other people have mentioned, I don't know if
>> there are any really large obstacles to targeting GCC to the 8051, or to
> 
> The biggest obstacles will be the severe lack of registers. But it's 
> possible, lm78 for example.


The 8051 is not very register-poor: it has a main accumulator and a 
secondary accumulator and four sets of eight general-purpose registers. 
The 32 general-purpose registers occupy the first 32 bytes of the 
internal data memory. A compiler could also use all of the directly 
addressable 128 bytes of internal data memory as registers, although the 
instructions that can use those "registers" are a little longer and a 
little slower.

If there is a problem for gcc, it may be that all those registers are 
only 8 bits wide, and cannot be used to address external data memory 
(although some of them can be used as 8-bit offsets in paged memory 
accesses). Only the Data Pointer Register (or registers, in newer 
variants) is wider and can be used to address external data memory.

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

[Gautier write-only address]

> 2. Some compiler we can start from 

Some possibilities for proceeding with HAC:
a. Adapt code generation to 8051 (it would create a branch of the HAC source...).
b. More ambitious: make the code generation multi-target using an abstraction.
c. A just-in-time compiler that translates p-code (the HAC VM code) to 8051.

For a. and b. the ideal point to consider is the HAC_Sys.Compiler.PCode_Emit package.

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

[Shark8]

On Wednesday, March 31, 2021 at 2:46:54 PM UTC-6, gautier wrote:
> c. A just-in-time compiler that translates p-code (the HAC VM code) to 8051. 
Is this the same p-code as the UCSD P-System?

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

[Gautier write-only address]

On Wednesday, March 31, 2021 at 11:14:49 PM UTC+2, Shark8 wrote:
> Is this the same p-code as the UCSD P-System?
They certainly have the same common ancestor.

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

[Shark8]

On Wednesday, March 31, 2021 at 3:25:23 PM UTC-6, gautier wrote:
> On Wednesday, March 31, 2021 at 11:14:49 PM UTC+2, Shark8 wrote: 
> > Is this the same p-code as the UCSD P-System?
> They certainly have the same common ancestor.
Awesome.
I had some documentation on the P-System a half-dozen years ago, and it seemed pretty nice from what I recall.

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

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:s3uskg$vif$1@gioia.aioe.org...
> On 2021-03-30 11:04, mockturtle wrote:
>
>> 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 think the efforts would be better invested in recycling all existing 
> 8051 cores. Make the planet greener! (:-))
>
> Honestly, there is little useful one could do in 64K. Remember what one 
> famous thinker and epidemiologist said about 640K? [640K is 10 times more 
> than 64K]

Gee, the early versions of Janus/Ada were *hosted* in 48K. Apparently, a 
compiler is nothing useful??? ;-)

We studied this problem back in the day (30+ years ago).The problem is the 
8051 architecture, which doesn't have a usable stack or the instructions to 
make one. You would have to avoid recursion and any long chain of calls. Not 
sure whether the result would program much like Ada, it would be much closer 
to Fortran 66.

                     Randy.

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

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:s3v3us$dfc$1@gioia.aioe.org...
> On 2021-03-30 13:27, mockturtle wrote:
>
>> Well, old ZX Spectrum with its 48K RAM extension (I and my brother said 
>> when we extended the RAM: "What are we going to do with all this memory?" 
>> :-D ) used just 64K and you could do nice stuff.  The first release of 
>> Turbo Pascal (editor and compiler integrated) was a .COM, limited by 
>> design to 64K.
>
> I remember the glorious time when 1K weighted 1kg (:-))
>
> When I started, I and my pal worked together on a 256K machine in two time 
> sharing terminal sessions. That was RSX-11M. These days almost every 
> executable begins at 5-10M.

You need to use a compiler (at least some of the time) that cares about size 
(i.e. Janus/Ada). Even Claw GUI programs usually don't exceed 0.5MB (and 
command line programs can be many times smaller). Smaller programs are often 
faster as well -- paging pressure is a real thing.

                                   Randy.

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

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:icgdhjF3j1eU1@mid.individual.net...
...
> 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.

Send $$$. ;-) This was a project that was ideally suited for the Janus/Ada 
compiler suite, but we never were able to find a customer for it. The 
problem is always that the first customer has to pay a substantial part of 
the development; later customers don't have to pay that freight. (Back in 
the "waiver" days we considered doing it for the "fun" of making DoD-types 
have to find better excuses to avoid Ada than a compiler not existing for 
it, but the likely ROI wasn't there to convince the angel investors to go 
along with the idea.)

                                     Randy.

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

[Randy Brukardt]

"Luke A. Guest" <laguest@archeia.com> wrote in message 
news:s40urd$qbp$1@gioia.aioe.org...
...
> AVR isn't really an accumulator arch, it's got 32 registers. Even the 6502 
> has a port, but that uses the zero page as virtual registers. The Z80 
> cannot do that as it starts executing from address 0 iirc.

The Z-80 has enough registers for Ada (or at least a reasonable subtest) --  
see the original Janus/Ada compilers. If you want *real* registers, even the 
x86 doesn't have enough registers for reasonable code optimizations. A 
"register architecture" is an iffy model for an intermediate language if you 
ask me.

                      Randy.

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

[Randy Brukardt]

"Gautier write-only address" <gautier_niouzes@hotmail.com> wrote in message 
news:ed21733d-64f0-473a-9a51-fe31fa327b10n@googlegroups.com...
> On Wednesday, March 31, 2021 at 11:14:49 PM UTC+2, Shark8 wrote:
>> Is this the same p-code as the UCSD P-System?
> They certainly have the same common ancestor.

So does Janus/Ada JCode. Not that that is relevant to anything today...

                        Randy.

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

[Luke A. Guest]

On 01/04/2021 00:20, Randy Brukardt wrote:
> "Luke A. Guest" <laguest@archeia.com> wrote in message
> news:s40urd$qbp$1@gioia.aioe.org...
> ...
>> AVR isn't really an accumulator arch, it's got 32 registers. Even the 6502
>> has a port, but that uses the zero page as virtual registers. The Z80
>> cannot do that as it starts executing from address 0 iirc.
> 
> The Z-80 has enough registers for Ada (or at least a reasonable subtest) --
> see the original Janus/Ada compilers. If you want *real* registers, even the

I know of the original Janus for Z80, never used it, is it a real Ada 
compiler or is it a Pascal like Ada? Have you considered compiling it as 
a cross compiler on Linux?

> x86 doesn't have enough registers for reasonable code optimizations. A

Tell me about it. Always hated the x86 when I was on m68k, look I have 8 
Data and 8 Address registers, you have what? 4 useable ones!

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

[Luke A. Guest]

On 31/03/2021 21:46, Gautier write-only address wrote:
>> 2. Some compiler we can start from
> 
> Some possibilities for proceeding with HAC:
> a. Adapt code generation to 8051 (it would create a branch of the HAC source...).

Generate TAC and then map those instructions to 8051 instruction 
sequences like ye olde compilers did.

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

[Niklas Holsti]

On 2021-04-01 2:14, Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
> news:icgdhjF3j1eU1@mid.individual.net...
> ...
>> 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.
> 
> Send $$$. ;-) This was a project that was ideally suited for the
> Janus/Ada compiler suite, but we never were able to find a customer
> for it. The problem is always that the first customer has to pay a
> substantial part of the development; later customers don't have to
> pay that freight. (Back in the "waiver" days we considered doing it
> for the "fun" of making DoD-types have to find better excuses to
> avoid Ada than a compiler not existing for it, but the likely ROI
> wasn't there to convince the angel investors to go along with the
> idea.)

Yes, things like that were among the reasons I had in mind for the lack 
of such Ada compilers. Plus the fact that the pain of writing a small C 
program is much less than the pain of writing a large C program.

If you think that targeting Janus/Ada to small microcontrollers is 
practical, I have two questions for you:

Can you describe, in general, the Janus/Ada internal program 
representation that, say, an 8051-back-end would get as input?

Would you be open to external/community participation in creating new 
back ends for Janus/Ada, either under NDA or working from a public 
definition of the internal representation, and either work-for-free or 
work for some share of future sales?

--
Niklas Holsti
Tidorum Ltd

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

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:icm5tmF7ak3U1@mid.individual.net...
> On 2021-04-01 2:14, Randy Brukardt wrote:
>> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
>> news:icgdhjF3j1eU1@mid.individual.net...
>> ...
>>> 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.
>>
>> Send $$$. ;-) This was a project that was ideally suited for the
>> Janus/Ada compiler suite, but we never were able to find a customer
>> for it. The problem is always that the first customer has to pay a
>> substantial part of the development; later customers don't have to
>> pay that freight. (Back in the "waiver" days we considered doing it
>> for the "fun" of making DoD-types have to find better excuses to
>> avoid Ada than a compiler not existing for it, but the likely ROI
>> wasn't there to convince the angel investors to go along with the
>> idea.)
>
> Yes, things like that were among the reasons I had in mind for the lack of 
> such Ada compilers. Plus the fact that the pain of writing a small C 
> program is much less than the pain of writing a large C program.
>
> If you think that targeting Janus/Ada to small microcontrollers is 
> practical, I have two questions for you:
>
> Can you describe, in general, the Janus/Ada internal program 
> representation that, say, an 8051-back-end would get as input?

It's called "JCode" (named long before Java existed, at least publically), 
and it is based on the ideas of p-code, tailored for what we needed for 8086 
and similar processor output. There are other inputs (mostly in the form of 
a partial JRL, which carries the unit dependencies and the like), but most 
of those are related to the binder.

Decent code generation for it is quite easy, since it is a rather low-level 
form. It's relatively easy to write a passable code generator and then 
incrementally improve it with pattern matching. One could probably build 
much fancier schemes on top of it; we thought about that periodically, but 
experiments showed that the differences wouldn't be worth the work. (Robert 
Dewar famously said that "most optimizations are disappointing", definitely 
a true fact from my experience.)

> Would you be open to external/community participation in creating new back 
> ends for Janus/Ada, either under NDA or working from a public definition 
> of the internal representation, and either work-for-free or work for some 
> share of future sales?

Yes, certainly. Contact me directly at the usual e-mail.

                          Randy.

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

[Randy Brukardt]

"Luke A. Guest" <laguest@archeia.com> wrote in message 
news:s44du6$ugk$1@gioia.aioe.org...
> On 01/04/2021 00:20, Randy Brukardt wrote:
>> "Luke A. Guest" <laguest@archeia.com> wrote in message
>> news:s40urd$qbp$1@gioia.aioe.org...
>> ...
>>> AVR isn't really an accumulator arch, it's got 32 registers. Even the 
>>> 6502
>>> has a port, but that uses the zero page as virtual registers. The Z80
>>> cannot do that as it starts executing from address 0 iirc.
>>
>> The Z-80 has enough registers for Ada (or at least a reasonable 
>> subtest) --
>> see the original Janus/Ada compilers. If you want *real* registers, even 
>> the
>
> I know of the original Janus for Z80, never used it, is it a real Ada 
> compiler or is it a Pascal like Ada?

It was an Ada 83 subset. Don't remember the exact details, but it covered a 
substantial part of the language, including packages and exceptions. The 
validated Ada 83 compilers were direct descendants, and the current compiler 
is directly descended from that.

> Have you considered compiling it as a cross compiler on Linux?

Sadly, we've lost the back-end. When I was moving and going to junk the last 
machine with a working 5 1/4" floppy, I decided to copy all of the old stuff 
into the version control system. But I wasn't able to read the disks with 
the source to the last pass.

I didn't concern myself too much with losing that, as that backend predated 
J-Code and thus any modern version would need to be rewritten anyway to mate 
with a modern front-end. I did manage to recover the runtime, which would be 
more work to reproduce anyway -- especially the floating point library.

>> x86 doesn't have enough registers for reasonable code optimizations. A
>
> Tell me about it. Always hated the x86 when I was on m68k, look I have 8 
> Data and 8 Address registers, you have what? 4 useable ones!

6 registers on the x86 (as SP and BP have special purposes -- one can use 
them [especially BP] in a pinch but you have to save the contents). It's 
just enough to be more than enough for most simple purposes and thus a bit 
of longer term register allocation is needed. The Z-80 for instance didn't 
need any register allocation as with essentially 3 there wasn't any point in 
trying to keep anything there.

                          Randy.

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

[Luke A. Guest]

On 02/04/2021 00:43, Randy Brukardt wrote:

>> I know of the original Janus for Z80, never used it, is it a real Ada
>> compiler or is it a Pascal like Ada?
> 
> It was an Ada 83 subset. Don't remember the exact details, but it covered a
> substantial part of the language, including packages and exceptions. The
> validated Ada 83 compilers were direct descendants, and the current compiler
> is directly descended from that.

Ah.

>> Have you considered compiling it as a cross compiler on Linux?
> 
> Sadly, we've lost the back-end. When I was moving and going to junk the last
> machine with a working 5 1/4" floppy, I decided to copy all of the old stuff
> into the version control system. But I wasn't able to read the disks with
> the source to the last pass.
> 
> I didn't concern myself too much with losing that, as that backend predated
> J-Code and thus any modern version would need to be rewritten anyway to mate
> with a modern front-end. I did manage to recover the runtime, which would be
> more work to reproduce anyway -- especially the floating point library.

Have you considered sticking the front end onto github? Writing a back 
end shouldn't be too hard. Would be an interesting project for someone, 
and also to get it up to complete Ada 83.