From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Hardware independent programming Date: Mon, 29 Jun 2020 12:07:43 +0300 Organization: Tidorum Ltd Message-ID: References: <5ef9712d$0$1221$e4fe514c@news.kpn.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net OmMfIi5NpNiEYzGQe5h9XA3bDhMSJ38vKkWJP1uoGNE9C+WX7J Cancel-Lock: sha1:AXmdBMGjSkdfpCRbWk7G7kLrV50= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: <5ef9712d$0$1221$e4fe514c@news.kpn.nl> Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:59245 List-Id: 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 . @ .