From: antispam@fricas.org   
      
   bart  wrote:   
   > On 27/11/2025 01:30, Waldek Hebisch wrote:   
   >> bart  wrote:   
   >>> And yet, integer widths have been roughly capped at double a machine   
   >>> word size for decades - until 64 bits came along and then few even   
   >>> bothered with double-width.   
   >>>   
   >>> Nobody thought how easy it would be to just have an integer of whatever   
   >>> size you like - you just generate whatever code is necessary to make it   
   >>> happen. We could have had BitInts on 32- and even 16-bit machines if   
   >>> only somebody had thought of it!   
   >>   
   >> PL/I had things like 'fixed binary(23)' (that is ability to   
   >> specify bit size) around 1965, but that stopped at machine   
   >> word length.  Pascal had range types, but similarly stopped   
   >> at at integer size.   
   >   
   > What were the reasons for PL/I to use odd sizes not related to word size   
   > or memory width?   
      
   One reason probably was theoritical elegance: program should say   
   how many bits _it_ needed, not how many bits computer has.   
      
   PL/I allowed such types as part of data structures, so they worked   
   as C bit fields.  With restriction on number of bits they would   
   need separate construct for bit fields.   
      
   Also, note that at that time IBM introduced 32-bit machines, but   
   also had older 36-bit ones.  Other manufacturers had 18-bit,   
   24-bit and 60-bit machines.  IBM wanted to ease convertion from   
   such machines.  I am not sure if they cared, but their definition   
   made possible implementing PL/I on such machines.  For example   
   GE implemented PL/I for their 36-bit machines.   
      
   BTW: I think that overflow in PL/I is an error (optionally   
   causing exception) so there is no need to implement wraparound.   
      
   >>  GNU Pascal allowed specifiying size in   
   >> bits and going to twice machine word (that was limitation   
   >> imposed by gcc backend).   
   >   
   > Before 64-bits, we needed double the word size in order to represent   
   > ordinary quantities. With 64 bits, there is much less need (hence few   
   > 128-bit types).   
      
   Less need, but it does not vanish.   
      
   >> And yes, such types could be added much earlier and it   
   >> is a shame that they are added only now.   
   >   
   > So what is the pressing need now?   
   >   
   > It is a mild convenience for those applications which really need   
   > numbers of 100s of bits, but not what I would have thought were worth   
   > making special provision for in a language.   
   >   
   > While they would be unwieldy for very much larger numbers, and in any   
   > case there are caps in place.   
      
   "worth" is subjective.  Simple implementation of largish numbers   
   (say Turbo Pascal quality) is not that complictated, basically   
   allocation of variables, assignment and similar are handled by   
   general code needed for other things.  So only arithmetic need   
   special implementation.  Here you need to generate inline code   
   for few small cases and runtime calls for other things.  Note   
   that compiler knows its runtime so could use special calling   
   convention so that calls are slightly cheaper than calls to   
   user-defined routines.   
      
   Multiple precision computations have at least one obvious use:   
   to verify correctness of computations at given precision   
   simplest approach uses higher precision.  This is not big   
   use, but valuable to developers, saving them effort to   
   create their own multiple precision routines.   
      
   IIUC in seventies Lisp implementations converged on supporting   
   arbitrary precision integers.  Lisp is garbage collected, so   
   in a sense Lisp users already "payed" for cost of dynamic   
   allocation so arbitrary precision is reasonably natural.   
   But one can also declare bit size (say 1159 bits) or   
   ranges and theoreticaly compiler can use this information   
   for optimization.  In lower level language one wants to avoid   
   dynamic allocation, so fixed size types are more natural.   
      
   I would say that if you are used to limited languages, then   
   you can cope reasonably well.  But availability of largish   
   integers makes some things easier.  Now I certainly do not   
   want to go back to using only languages which do not support   
   them.  For me support for larger numbers in Clang and gcc is   
   really good news (reading standard suggested that compilers   
   may put upper limit quite low).   
      
   > I can see some use when you want a block datatype or so many bytes   
   > (sorry, bits, since it needs to be bit-precise even at the large scale),   
   > especially if some bitwise ops are available.   
   >   
   > Eg. do some of the things that Pascal bit-sets were used for, but   
   > there's still seems to be lots of support lacking.   
   >   
   > So it still appears to me a rather heavyweight feature, in a lightweight   
   > language, that is lacking in everyday use-cases.   
      
   IIUC is is light in a sense that compiler is not obliged to support   
   bigger integers than it already supported.  So the only new thing is   
   masking for unsigned types of strange sizes.  Gain is that   
   on 8-bit processors (still important in embedded area) users   
   can now request 8-bit type and get all computaions in 8 bits   
   (without useless promotion to 16 bits mandated for older types).   
      
   >> Part of reason may be that in nineties usage of other   
   >> (than C) lower level languages went down.  C was   
   >> traditionally quite minimal and did not want new to   
   >> introduce new features.   
   >   
   >   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)