Re: Hardware independent programming

[alby.gamper@gmail.com]

On Monday, June 29, 2020 at 7:07:45 PM UTC+10, Niklas Holsti wrote:
> On 2020-06-29 7:42, ldries46 wrote:
> > Hardware can in some cases have limits you have to consider when writing 
> > a program.
> >   At this moment I can mention three:
> > 
> > 1. The printer. The format of the documents you want to print must fit
> >     on the printers available to the user. In general the problem is
> >     solved by the possibility of printer drivers to shrink you document
> >     f.i. from A4 to A4 or saving the document to a file that can be
> >     printed elsewhere.
> 
> Such info belongs in a text-formatting library (possibly part of a GUI 
> library). I would welcome a standard definition of "type text" that 
> would include some formatting structures (perhaps semantically similar 
> to HTML formatting) but I think it would (and should) be low in priority 
> for language standardization. For now, we can hope that some 
> community-supported library becomes a de-facto standard.
> 
> > 2. The monitor on the system your program is running.
> 
> Such info belongs in a GUI library. GUI functions do not belong in the 
> Ada standard, IMO.
> 
> > 3. The available memory. Your program will in some cases need to know
> >     the limits to which the heap stretches within the memory (in cases
> >     where it is necessary  to use very large bulks of data). For
> >     operating systems that have the possibility to stretch the heap with
> >     a part on disc both boundaries (with and without disc data) are of
> >     interest.
> 
> Something like that might be suitable for the Ada standard, to cater for 
> the (few) programs that could adjust their memory usage to reduce the 
> risk of thrashing, for example.
> 
> However, a description of the memory HW could easily balloon to a 
> cumbersome size and complexity if it should reflect the full memory 
> architecture, such as the sizes of all cache levels, the structure of 
> the caches (line length, associativity, etc.), the presence of per-core 
> caches or cache partititions, the presence of memories of different 
> types/speeds/sizes, the presence of several memory interfaces and 
> controllers, the paging/swapping methods, etc.
> 
> Even if something could be defined now for all of that, it might quickly 
> become obsolete as computer HW continues to evolve.
> 
> -- 
> Niklas Holsti
> niklas holsti tidorum fi
>        .      @       .

Hi Niklas

I agree with you point 3) on memory availability! MS Windows and I am sure
Linux have Api's available to surface this to Ada. What may become somewhat
problematic is in the embedded OS/RTOS environments like RTEMS etc..

Happy to contribute to a high level spec and implement for MS Windows

Alex