Re: SweetAda 0.1e released

[Roger Mc <rogermcm2@gmail.com>]

On Tuesday, July 28, 2020 at 7:16:59 PM UTC+10, gabriele.g...@gmail.com wrote:
> On Tuesday, July 28, 2020 at 2:06:46 AM UTC+2, Roger Mc wrote: 
> > On Tuesday, July 28, 2020 at 2:04:52 AM UTC+10, gabriele.g...@gmail.com wrote: 
> > > In sweetada context, QEMU is a more or less normal QEMU that is used as an aid in development. e.g.,if you want to try sweetada code on a MIPS cpu, or a PowerPC, maybe it is better to exercise on an virtual machine. That's why exists a QEMU. QEMU is patched so that every machine it could emulates has additional I/Os that normally do not exist in that machine. Like a generic I/O card inside a computer. For example, if you choose a SPARC cpu (an thus an emulated machine like a SPARCstation5), it is difficult to have immediate evidence, because you have to low-level program a huge number of things, like the video framebuffer. Instead, you manipulate those simple I/O and IOEMU lets you visualize them on his own window. QEMU package is a normal QEMU distribution (apart the patches, that I have to make public soon, just the time to adjust them in a decent form), and IOEMU is an indipendent library added inside the distribution, but it's nothing more that a GUI manager for widgets, together with a parser for ioemu.cfg configuration files. Again I will release the source once that the code is cleaned up and stable. I make huge changes everyday, and don't want ugly things spreading off the net. 
> > > 
> > > By the way, you can run QEMU without IOEMU, just delete the library file. Then supply QEMU with your own firmware by standard command line options. QEMU for sweetada has nothing different. 
> > > 
> > > To be honest, if you want to study QEMU from a low-level point of view, prepare yourself for a long journey. It's incredibly complicated. And Sweetada does help you very little in doing that. The focus of sweetada is currently to adapt Ada code to machines. 
> > > 
> > > G 
> > 
> > Great! I finally get the picture (well, almost). 
> > QEMU is /opt/sweetada/bin/qemu-system-x86_64 which starts up like a DOS PC, booting from ROM and running until it can't find a bootable device. 
> > Also, the QEMU-AArch64 directory gives me plenty of clues. 
> > 
> > My idea is certainly, not to study QEMU from a low-level point of view but to understand its use in the context of sweetada and to understand the adaption of Ada code to machines. 
> > My planned first job is to completely identify and understand all interfaces between sweetada and QEMU.
> Well, absolutely. 
> 
> The flow is the following: 
> 
> - make all -> kernel.elf creation 
> - make postbuild --> kernel.rom ROM BIOS image (or whatever is used by the target) 
> - make run --> execute the "RUN_COMMAND" specified in configuration.in 
> - in the case of PC-x86-64, runsweetada is called 
> - runsweetada parses the START section of ioemu.cfg and executes QEMU for a PC x86-64 
> - qemu-system-x86_64 starts, it loads the ROM BIOS image and the emulated CPU runs sweetada code 
> - if the IOEMU library is present, it parses ioemu.cfg again, looking into I/O and serialport sections, creates the IOEMU window that displays physical I/O ports and starts terminals connected to the serialports of the emulated machine 
> 
> In the case of QEMU-AArch64 nothing changes, obviously the system code is different and qemu-system-aarch64 is called. You do not see anything in the QEMU window because a fictional board gets emulated, which does not have a VGA screen, only CPU, RAM and some undisplayable peripherals. The image produced by sweetada is not a true ROM image because this fictional board does not have an easily mappable ROM, so it directly loads the kernel.elf object. 
> 
> Regards
Thanks Gabriele.  As usual, very helpful.