556278a5   
   Hi,   
      
   On Tuesday, October 30, 2012 2:31:07 PM UTC-5, Jim Leonard wrote:   
   > On Oct 30, 12:18 pm, Vinzent Höfler   
   >    
   > <0439279208b62c95f1880bf0f8776...@t-domaingrabbing.de> wrote:   
   >    
   > > Jim Leonard  wrote:   
   >    
   > > >   l:=w1 * w2; {Throws runtime 215 "arithmetic overflow" if $Q+}   
      
   I only can test TP 5.5, and it doesn't seem to support $Q+ at all.   
       
   > > Keep in mind that TP is a 16-bit compiler, it doesn't use 32-bit   
   arithmetic by default.   
   >    
   > One would think that the compiler would be smart enough to output code   
   > appropriate for the size of the  destination  -- I guess not!  I'm   
   > quite surprised I haven't encountered this before, and I've been   
   > writing programs with TP7 on and off for 20 years.   
   >    
   > I quickly tested casting one of the operands to   
   > longint() and that worked, thanks for the suggestion.   
      
   Yeah, for TP 5.5, it works fine if w1 and w2 are both defined as "longint" but   
   not if they are "word".   
      
   Keep in mind that the compiler probably isn't aware that your "word"s are   
   small enough to not overflow at multiply, which may or may not be a bug.   
   Probably in the interest of efficiency, it decided to always do "word"   
   arithmetic in word registers instead    
   of always using slower "longint" calculations on the rare chance that it might   
   overflow. I guess it can't (easily?) figure out what's best by heuristics.   
   (Perhaps on overflow it should promote to larger type, if available, and try   
   again.) Some languages    
   just use bigint all the time for simplicity [REXX, Scheme?], but that's   
   obviously less efficient than fixed size (native) register types.   
      
   I'm not totally sure what the Pascal standard(s) say about signed vs. unsigned   
   numbers, overflow, etc. Though official Pascal doesn't even have "longint"   
   (32-bit signed) nor "word" (16-bit unsigned) as distinct types.   
      
   And 16-bit does complicate things a bit when trying to support 32-bit numbers,   
   as I've noticed in various 16-bit compilers. So there are sometimes   
   restrictions on array indices, "for" variables, what built-ins (e.g. INC) will   
   support, etc. Even "case"    
   expression sometimes must be short. It honestly depends on the compiler! (I'm   
   mainly thinking of the following 16-bit: ACK, FST, Oberon-M.)   
      
   Modula-2 was more complicated than "standard" Pascal due to CARDINAL, but that   
   was added because of native machine support of it and due to 16-bitness of the   
   original CPUs, so it was more useful for addressing on those old machines.   
   Both Modula-3 and    
   Oberon simplified type compatibility a bit but in different ways. Modula-3   
   just made CARDINAL the positive subset of INTEGER; Oberon removed CARDINAL   
   completely (as Ceres was 32-bit) but did have LONGINT and SHORTINT. Yet even   
   that can cause complication    
   and confusion in some obscure cases, so Wirth went ahead and removed them   
   entirely from Oberon-07.   
      
   In short, it's hard to make an easy-to-use type system that works for 16-bit,   
   32-bit, 64-bit, etc. Sadly, most languages and implementations seem to assume   
   too many things these days, esp. 32-bit or 64-bit or POSIX or Windows with   
   Unicode and multi-   
   threading, so it makes portability that much harder unless you go the easy   
   (obvious) route of just using whatever's popular (i.e. not DOS).   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)