Hardware independent programming

Hardware independent programming

[ldries46]

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.
 2. The monitor on the system your program is running. Creating a window
    that is to large for your screen resolution can be trouble some but
    you do not know the resolution of the the customer using your
    program. The solution for such a problem can only be hardware
    independent programming. Your program should know the resolution of
    your screen and adjust to  that or in the worst case decide that
    system is not suitable for the program.
 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.

There should be a package in Ada that like GNAT.OS-lib does with 
operating system differences, makes such hardware parameters available 
for the programmer.

Re: Hardware independent programming

[Niklas Holsti]

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

Re: Hardware independent programming

[alby.gamper]

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

Re: Hardware independent programming

[Shark8]

On Sunday, June 28, 2020 at 10:42:22 PM UTC-6, 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.
This is a solved problem with PostScript; and has been for literally decades.

>  2. The monitor on the system your program is running. Creating a window
>     that is to large for your screen resolution can be trouble some but
>     you do not know the resolution of the the customer using your
>     program. The solution for such a problem can only be hardware
>     independent programming. Your program should know the resolution of
>     your screen and adjust to  that or in the worst case decide that
>     system is not suitable for the program.
There are similar solutions to the postscript model; hell, Borland's BGI in the late 80s handled this problem. There was even an extension to Postscript: Display PostScript. — That you are having issues with this problem now, after decades of experience, is illustrative of my thesis that C and C++ has set the industry back decades.

>  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.
Memory management is... tricky. Besides being rather technical and needing precise adherence to a particular model, oftentimes that sort of low-level thinking gets in your way. -- There was an excellent Guy Steele talk (I think it was "How to think about parallel programming. NOT!") where he made an analogy between memory management and parallel processing, noting how just as the explicit-style of earlier years (ie "put this value into a register") got in the way of more advanced register-allocation so too is the accumulator/sequential-solution going to get in the way of parallelization.

> There should be a package in Ada that like GNAT.OS-lib does with 
> operating system differences, makes such hardware parameters available 
> for the programmer.
Possibly. The problem is that there's a *LOT* of [possible] parameters, and you'd have to multiply that by all your targets, so that's a lot of extra work to foist on Ada implementers. — I'm not saying that it isn't a good idea, just that it's a lot of work... though this could be mitigated, perhaps, if the Ada/OS interfaces weren't sometimes done the stupid way around (eg directory-paths as strings rather than as lists).

Re: Hardware independent programming

[ldries46]

Op 29-6-2020 om 6:42 schreef ldries46:
> 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.
> 2. The monitor on the system your program is running. Creating a window
>    that is to large for your screen resolution can be trouble some but
>    you do not know the resolution of the the customer using your
>    program. The solution for such a problem can only be hardware
>    independent programming. Your program should know the resolution of
>    your screen and adjust to  that or in the worst case decide that
>    system is not suitable for the program.
> 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.
>
> There should be a package in Ada that like GNAT.OS-lib does with 
> operating system differences, makes such hardware parameters available 
> for the programmer.
>
I know, I just said something that can create a lot of discussion, but 
one of the reasons that Ada was created was that programs were often not 
portable from one operating system to another for the simple reason that 
on one system another set op routines was used as on another operating 
system, or even new versions of the same OS.
When different hardware is going to create the same type of problems my 
view is that to save that reason for the existence of Ada asks also for 
a form of hardware independency. Yes there are probably more hardware 
problems to be solved and no, I do not have solutions for all.
But let me make a suggestion, use environment variable on a standard way 
in all operating systems then Ada can pick them up and use them:
On my Windows 10 Operating system the variable OS="Windows_NT" is put 
there by Windows itself, On my Linux(Ubuntu) system the variable did not 
exist so I made it myself OS="Linux" now the .gpr file can differentiate 
between operating systems.
For Screens the values Screen_Width and Screen_Height should be defined 
for Software like Gtk, Qt and Gnoga to know what the resolution of the 
screen is, and at least give you the possibility to make your program 
fit on all screens / graphical cards. Even a parameter MEM_AVAIL could 
be usefull.

I know this are items to be resolved in an OS but a language like Ada 
could use the in a Package to make your program hardware independent.

Re: Hardware independent programming

[ldries46]

This is how such a Package could look like:

with Ada.Environment_Variables; use Ada.Environment_Variables;
with Debugging;                 use Debugging;

package body Hardware is

    function Operation_System return Unbounded_String is
       OS : Unbounded_String := To_Unbounded_String("No System");
    begin
       if Exists("OS") then
          OS := To_Unbounded_String(Value("OS"));
       end if;
       return OS;
    end Operation_System;

    function Resolution(Screen_nr : positive := 1) return 
Screen_resolution is
       Scr  : Screen_resolution;
       str  : Unbounded_String;
       Name : Unbounded_String;
    begin
       str := To_Unbounded_String(integer'image(Screen_nr));
       while Slice(str, 1, 1) = " " loop
          str := To_Unbounded_String(Slice(str, 2, Length(str)));
       end loop;
       Name := To_Unbounded_String("Screen_Width_") & str;
       if Exists(To_String(Name)) then
          Scr.width := integer'value(Value(To_String(Name)));
          Print_Line(Name);
       end if;
       Name := To_Unbounded_String("Screen_Heigth_") & str;
       if Exists(To_String(Name)) then
          Scr.heigth := integer'value(Value(To_String(Name)));
          Print_Line(Name);
       end if;
       return Scr;
    end Resolution;

end Hardware;

Re: Hardware independent programming

[ldries46]

Op 29-6-2020 om 6:42 schreef ldries46:
> 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.
> 2. The monitor on the system your program is running. Creating a window
>    that is to large for your screen resolution can be trouble some but
>    you do not know the resolution of the the customer using your
>    program. The solution for such a problem can only be hardware
>    independent programming. Your program should know the resolution of
>    your screen and adjust to  that or in the worst case decide that
>    system is not suitable for the program.
> 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.
>
> There should be a package in Ada that like GNAT.OS-lib does with 
> operating system differences, makes such hardware parameters available 
> for the programmer.
>
If we want to create hardware or operating system independent programs 
it is in some situations necessary to use environmental variable from 
which a package in Ada or in other languages can get values from.
The names of these values should then in all these systems the same. I 
found that in Windows OS is such a variable for the name of the 
operating system (OS=Windows_NT) In Linux(Ubuntu) I could not find such 
a variable so it looks logical to use OS=Linux. For other parameters 
standard names should be found. So the ada packages I mentioned is not 
the only thing that must be done.

Re: Hardware independent programming

[Dmitry A. Kazakov]

On 02/07/2020 08:15, ldries46 wrote:

> If we want to create hardware or operating system independent programs 
> it is in some situations necessary to use environmental variable from 
> which a package in Ada or in other languages can get values from.
> The names of these values should then in all these systems the same.

It is the OS and the OS major release, e.g. like WIN32_WINNT numbers: 
16#400# is NT 4.0, 16#502 is XP etc. It is the architecture x86_64, 
armhf etc. It is the host machine and target machine in the case of 
cross compiling.

But most of this can be abstracted away if AdaCore put more efforts 
into. E.g. the notorious case is pragma Atomic. If the compiler 
supported it for all architectures there would be almost no need to 
distinguish 32 and 64-bit targets.

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