comp.lang.ada
 help / color / mirror / Atom feed
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Subject: Re: Hardware independent programming
Date: Mon, 29 Jun 2020 12:07:43 +0300	[thread overview]
Message-ID: <hltpb0Ff23mU1@mid.individual.net> (raw)
In-Reply-To: <5ef9712d$0$1221$e4fe514c@news.kpn.nl>

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

  reply	other threads:[~2020-06-29  9:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-29  4:42 Hardware independent programming ldries46
2020-06-29  9:07 ` Niklas Holsti [this message]
2020-06-29 12:22   ` alby.gamper
2020-06-29 14:11 ` Shark8
2020-06-30  6:28 ` ldries46
2020-06-30  6:35   ` ldries46
2020-07-02  6:15 ` ldries46
2020-07-02  7:25   ` Dmitry A. Kazakov
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox