Groups | Search | Server Info | Login | Register

Groups > comp.lang.pascal.borland > #131

Re: longint and/or overflow bug?

Show all headers | View raw

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 <mobyga...@gmail.com> 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).

Back to comp.lang.pascal.borland | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

longint and/or overflow bug? Jim Leonard <mobygamer@gmail.com> - 2012-10-30 08:56 -0700
  Re: longint and/or overflow bug? Vinzent Höfler <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> - 2012-10-30 18:18 +0100
    Re: longint and/or overflow bug? Jim Leonard <mobygamer@gmail.com> - 2012-10-30 12:31 -0700
      Re: longint and/or overflow bug? rugxulo@gmail.com - 2012-10-30 14:50 -0700
  Re: longint and/or overflow bug? Marco van de Voort <marcov@toad.stack.nl> - 2012-10-31 09:35 +0000
    Re: longint and/or overflow bug? Marco van de Voort <marcov@toad.stack.nl> - 2012-10-31 10:11 +0000

csiph-web