3 ms·

Along those lines... on MS-DOS/x86, memory model support in (Turbo) Pascal was less flexible than in Turbo C (1.0) during the first years when those toolchains

by cagey 5y ago

Along those lines... on MS-DOS/x86, memory model support in (Turbo) Pascal was less flexible than in Turbo C (1.0) during the first years when those toolchains were competing and gaining critical mass: TP 3.0 generated COM files (near code, near data, far heap-allocated data). TP 4.0 generated EXE files (far code, near data, far heap-allocated data). (the above is "to the best of my recollection": I no longer have the manuals for these toolchains; it might be the case that in TP 4+ all data is far (pointers to data were far)). A TP coder was generally forced to live within these constraints (and adapt to the memory model changes described above across the 3 -> 4 transition). Turbo C 1.0 came along within a year or so of TP 4.0, and (because it was actually not a 1.0 implementation but a rebranding + enhancement of an existing toolchain acquired by Borland) supported all permutations of x86 memory models, allowing the coder to choose according to their needs (and explicitly define near and far functions and data as needed independent of the memory model used w/o a need to drop into [inline] asm). Turbo C's giving the programmer total control and optimization flexibility along these axes, which was a function of the language _implementations_, not the languages themselves, I believe contributed to the "C was faster" outcome (from TP 4 onward, there was (inline asm aside) IIRC no way to instantiate near functions). Turbo C was not the only C implementation for MS-DOS, but IIRC it immediately became the most popular, and held that crown for many years; other entrants needed to match Turbo C's features or die. [edit] Microsoft offered a MS-DOS C compiler (long?) prior to the release of TC 1.0, which supported the same memory-model permutations as TC 1.0. However it was at least 3x more expensive than TC 1.0, so when TC 1.0 was released at such a low price, it grabbed a lot of market share (by expanding the market to include programmers with smaller budgets). There were at least a few more MS-DOS C toolchain competitors already on the market when TC 1.0 was released (but I never used them so cannot comment futher on them).

pjmlp 5y ago
Apparently you missed the whole TP 5.0, 5.5, 6.0, 7.0 and TPW 1.5 offerings. And Turbo C 2.0 was quickly replaced by Turbo C++.
- cagey 5y ago
  > Apparently you missed the whole TP 5.0, 5.5, 6.0, 7.0 and TPW 1.5 offerings. I didn't miss them, but because IIRC all the versions you mentioned (and also Delphi 1.0) were x86 16-bit (only) Borland/Turbo Pascal evolutions having effectively the same memory model support as TP 4.0, felt they were not important to enumerate. These releases certainly added other features, but IIRC made no architectural changes affecting the performance of their generated code on the 16-bit x86 platform. (Again IIRC) all Borland C/C++ variants >= TC 1.0 offered the same 16-bit x86 memory model (and ability to manually mixing memory models) support (that already being comprehensive), with gradually improving codegen optimizations. My larger proposition is that the perception of (Turbo) Pascal's performance being perceived as poorer than that of C (in the interval when Pascal was being eclipsed by C/C++), while accurate, was influenced to some degree by the incidental factor of the dominant x86 CPU architecture of the day having a segmented architecture upon which extraction of optimal performance across the range of applications necessitated the extensive/comprehensive memory model support found in all competitive C/C++ compilers of that day, which none of the competing Pascal compilers (which is to say: Borland's plus MS' QuickPascal (which implemented the Borland language definition [1])) possessed. It would have taken those Pascal vendors more resources to add such memory model support (and other optimizations offered by their C/C++ competition), and they elected not to do so. Borland moved on to Delphi which continued the pattern wherein raw performance of the Pascal compiler's generated code (x86 32-bit as well as 16-bit) lagged behind that of the C/C++ competition; Borland's finite resources were expended on the IDE & RAD aspect of Delphi rather than on codegen. "The rest is history". But I don't think there was anything intrinsic to Borland's Pascal dialect (the only one I ever used) which doomed it to take a backseat to C in terms of performance: I used both TC and TP 4+ without ever feeling a vast difference between the two languages (and found many aspect of Pascal preferable to those of C/C++). [1] https://en.wikipedia.org/wiki/Microsoft_Pascal https://en.wikipedia.org/wiki/Microsoft_Pascal
  - pjmlp 5y ago
    Borland Pascal compilers that I mentioned had exactly the same memory models than their C++ counterparts, specially the Windows 3.1 versions, there was no difference between TPW 1.5 and TC++ 3.1. Borland Pascal 7.0 introduced support for protected mode.

by cagey 5y ago

pjmlp 5y ago

Apparently you missed the whole TP 5.0, 5.5, 6.0, 7.0 and TPW 1.5 offerings. And Turbo C 2.0 was quickly replaced by Turbo C++.

cagey 5y ago
> Apparently you missed the whole TP 5.0, 5.5, 6.0, 7.0 and TPW 1.5 offerings. I didn't miss them, but because IIRC all the versions you mentioned (and also Delphi 1.0) were x86 16-bit (only) Borland/Turbo Pascal evolutions having effectively the same memory model support as TP 4.0, felt they were not important to enumerate. These releases certainly added other features, but IIRC made no architectural changes affecting the performance of their generated code on the 16-bit x86 platform. (Again IIRC) all Borland C/C++ variants >= TC 1.0 offered the same 16-bit x86 memory model (and ability to manually mixing memory models) support (that already being comprehensive), with gradually improving codegen optimizations. My larger proposition is that the perception of (Turbo) Pascal's performance being perceived as poorer than that of C (in the interval when Pascal was being eclipsed by C/C++), while accurate, was influenced to some degree by the incidental factor of the dominant x86 CPU architecture of the day having a segmented architecture upon which extraction of optimal performance across the range of applications necessitated the extensive/comprehensive memory model support found in all competitive C/C++ compilers of that day, which none of the competing Pascal compilers (which is to say: Borland's plus MS' QuickPascal (which implemented the Borland language definition [1])) possessed. It would have taken those Pascal vendors more resources to add such memory model support (and other optimizations offered by their C/C++ competition), and they elected not to do so. Borland moved on to Delphi which continued the pattern wherein raw performance of the Pascal compiler's generated code (x86 32-bit as well as 16-bit) lagged behind that of the C/C++ competition; Borland's finite resources were expended on the IDE & RAD aspect of Delphi rather than on codegen. "The rest is history". But I don't think there was anything intrinsic to Borland's Pascal dialect (the only one I ever used) which doomed it to take a backseat to C in terms of performance: I used both TC and TP 4+ without ever feeling a vast difference between the two languages (and found many aspect of Pascal preferable to those of C/C++). [1] https://en.wikipedia.org/wiki/Microsoft_Pascal https://en.wikipedia.org/wiki/Microsoft_Pascal
- pjmlp 5y ago
  Borland Pascal compilers that I mentioned had exactly the same memory models than their C++ counterparts, specially the Windows 3.1 versions, there was no difference between TPW 1.5 and TC++ 3.1. Borland Pascal 7.0 introduced support for protected mode.