• englebert (unregistered) in reply to Aoun Somny
    Aoun Somny:
    I'm betting the language involved was actually Pascal, since Apple was pushing Pascal when the Mac first came out, and only later switched to C. (If you look through the old Toolbox API for C, circa 1995, you'll see lots of functions declared as "pascal void" or whatever, and of course the Str255 data type was all over the place.

    Turbo Pascal on the Mac did rule for quite a while.

    Most APIs use Pascal calling convention for speed. The only requirement is a fixed argument list. Pascal calling convention requires that the callee cleans the stack. This allows a return with stack adjustment as a single operation. Every instruction cycle was really important when we used to run Windows 2.1 on 12Mhz 286 boxes. (It was amazingly fast, even on those new fangled 640x480 VGA monitors)

    C calling convention requires that the caller cleans the stack (This is what allows variable argument lists, ...). This means the the callee just returns, the caller then performs a second operation to reclaim the stack space used by the function arguments.

    All of the old Windows APIs (and probably the new OS level ones) used Pascal calling convention even though all of the development tools were in C.

    Captcha: captcha? I hope this works...

  • jondr (unregistered) in reply to Anonymous Coward
    Anonymous Coward:
    What happened to the original FORTRAN version?

    Well, in 1977 it became the Fortran version.

    captcha: billgates

  • (cs) in reply to Aoun Somny

    "I suspect that the "FORTRAN" is part of the anonymization; if this was really for the Mac, I'm betting the language involved was actually Pascal, since Apple was pushing Pascal when the Mac first came out, and only later switched to C."

    I actually wrote FORTRAN software on the Mac back in the day. Believe it or not since the Mac has always leaned toward the GUI Interfaces, the FORTRAN compiler that was available had a direct link into the OS routines and a complete API that allowed GUI interfaces to be written completely in FORTRAN.

    It was actually really nice..and it was blazing fast for its time. I once benchmarked one program I wrote on a 16 MHz Mac IIci (Motorola 68020), a 32 MHz IBM PC (Intel 386 Winders 3.1, Sun Sparc One, and VAX Mini Micro. The Mac version was over 2 Minutes faster in run time over the PC, 3 minutes faster than the Sun and ~30 sec faster than the VAX. It was .. in a word... a kick-ass FORTRAN implementation. And since the Apple Math engine at the time was REALLY good (90 bits of Math accuracy, 1st NAN error codes, cos(180) = 0 exactly....not out to some arbitrary decimal length. I had already dropped my Cray account in favor of the Mac a couple years earlier.

    Oh and FORTRAN is still used in science pretty heavily since even though a lot of the really complex Math libraries are still more powerful for that language than in any other. FORTRAN has been able to do Graphics since the early 70s....Anyone remember DISSPLA?? Completly written if FORTRAN.

    That's the package I started in computers with....I was making movies in the early 80s at $700 per CPU hour on a Cray II.

    Wheee!!

  • disaster (unregistered) in reply to hexatron
    hexatron:
    >Couldn't you just subtract one from the array pointer so that newArray[1] == oldArray[0], allowing you to loop from 1 to 4?

    My father had a story: A man went to a tailor to get a suit made. When he tried it on, the fit was miserable. "One leg is shorter than the other!" "So stand a little tilted--it'll look fine!" "The shoulders aren't even either!" "So bend one shoulder down--you'll look great!"

    The man hobbled out of the shop as the tailor had directed.

    On the street, another man started talking to him: "Where did you get that wonderful suit?" "At the shop over there. But I don't think it's so wonderful." "Whaddya mean? That tailor must be a genius to fit such a nice suit on a cripple like you!"

    So sure. Subtract one from all the pointers. Why does the program keep crashing in 'delete'?

    Fortran arrays, since f77, don't start at 1 - they can assume any range e.g. my_array(100:100). Converting a lot of those to start at 0 would require careful bookkeeping.

  • Phil Boswell (unregistered) in reply to Dustin
    Dustin:
    jbl:
    non-believer:
    Myself, I was a lot better with FORTRAN IV (and FORTRAN II).

    I don't even remember what FORTRAN I was taught and haven't used it since. I can't even remember if it was interpreted or compiled. So I don't really know what a mid 1990s FORTRAN compiler was capable of.

    The last (and just about only) time I recall writing FORTRAN was in about 1984 as part of my CompSci course at UCL, where we wrote a tiny program which was squirted down a pipe to a Cray, just as a demonstration of how this system worked.

    The compiler, as I recall, was pretty capable, yes. But who cared? The Cray glommed it up and spat it out in a fraction of a second HOWEVER badly you wrote it ;-)

  • hexatron (unregistered) in reply to Gareth Martin
    Gareth Martin:
    hexatron:
    >Couldn't you just subtract one from the array pointer so that newArray[1] == oldArray[0], allowing you to loop from 1 to 4?

    So sure. Subtract one from all the pointers. Why does the program keep crashing in 'delete'?

    This is assuming he's using new and delete (or malloc and free etc), and not static arrays.

    But anyway, to avoid the "delete" problem just add one again before you use delete, or store the altered pointer separately. All languages with a 1-based array either internally keep a pointer to one element before the start of the array, and offset from that, or they subtract 1 from the index you ask for on every array access, so just emulate one of these. Alternatively you could just make the arrays 1 larger and ignore the 0 element, which will also work flawlessly. Or for yet another solution, just redefine the array versions of new and delete to return and expect a pointer to the element before the start of the array. Would save a lot of hunting down all the arrays to alter them (of course only works on dynamically allocated arrays).

    Re the above paragraph--see the original tailor story--your solution is 'walk funny.'

  • hexatron (unregistered) in reply to J Random Hacker
    J Random Hacker:
    @hexatron

    "My father had a story: A man went to a tailor to get a suit made..."

    Famous old joke. I believe it was originally told about "demob suits", the civilian clothes issued to British soldiers after WW2.

    My father probably heard it in the 1920's, his heyday of yiddish comedy. I suspect the original story was something like "Ramses asked Thutmose to make him a new loincloth..."

  • hexatron (unregistered) in reply to Heinz Gorgon Mittelmacher
    Heinz Gorgon Mittelmacher:
    Mike:
    newfweiler:
    There was only one problem. It was an accounting package that used floating-point for money and the other computer had 36-bit words. The 370 has 32-bit words. We had to convince the customer that $123,321.06 plus $123,321.06 really equalled $246,642.13.
    Where I learned programming I was tought to never ever use floats for financal calculations and to go with integers instead.
    You were taught right. And your are right: it's all too common. And as far as I know, there are no easy ways to solve the rounding issues once you have a 750000-line business app written in C that consistently uses floats for currency.

    *s/float/double/g and if he has more than $1.7E+306, screw him.

  • (cs) in reply to englebert
    englebert:
    C calling convention requires that the caller cleans the stack (This is what allows variable argument lists, ...).

    That's a myth. Nothing in ISO 9899 "requires that the caller [clean] the stack". While there are various requirements for how functions are called and how function calls behave, provided the program does not invoke undefined behavior, that isn't one of them.

    It's perfectly permissible to implement variadic function calls with a hidden extra parameter that tells the called function how to clean up, for example.

    There are platforms which use the same ABI for C and Pascal, with none of this "calling convention" nonsense (eg AIX on PPC). There are C implementations on systems that provides direct support for variadic calls, and the C implementation doesn't worry about "cleaning up the stack" at all (eg EPM C on AS/400).

    -- Michael Wojcik

  • englebert (unregistered) in reply to MichaelWojcik
    MichaelWojcik:
    englebert:
    C calling convention requires that the caller cleans the stack (This is what allows variable argument lists, ...).

    That's a myth. Nothing in ISO 9899 ... It's perfectly permissible to implement variadic function calls with a hidden extra parameter that tells the called function how to clean up, for example.

    ISO 9899 was not adopted until 1999, we were talking about technologies that were available in mid to late 1980's.

    I agree, that Pascal vs. C calling idiom is more of a Windows (antiquated) API convention. I think they call it stdcall or something now.

    Your own rebuttal provides evidence that the caller must at least provide extra information (overhead) to the callee for cleanup purposes. Fixed parameter lists will always allow more options for platform specific optimizations.

  • NotARobot (unregistered)

    Ahh, this one brought back the memory of when I was asked to knock up a little database program to print out name and address labels of our customers - doing it with the word processor mail-merge was a pain, apparently. I hacked something together in Clipper (anyone remember Clipper?) that did the bare minimum.

    A week or so later, the company sales rep dropped a glossy leaflet on my desk. "What about this then?" he asked, smugly. The leaflet said "Marketing Manager!" in shouty bold letters and continued: "Organise and store your customer information, search and sort on multiple fields, print lists, letters, labels...", etc.

    I groaned - "Wow, that looks great - but I wish you'd told me we were selling this, because I needn't have wasted a couple of days hacking that crappy label printing thing!"

    "No, no," he said, "You don't understand, this is the label printing program you wrote..."

    I groaned even louder.

  • Scotty (unregistered) in reply to teacher
    teacher:
    jrwr:
    They should of just kept it as FORTRAN and shipped it.... maybe he still will as OSS

    Captch: Knowhuntimean ( ??!! )

    I feel for The Professor - maybe if he had built it out of coconuts...

    He did, but the Skipper was head of rewrite and Gilligan was the lead developer.

  • Anonymous (unregistered) in reply to nobody
    Why do I think many of the stability problems were due to the difference between FORTRAN arrays (1-based) and C++ arrays (0-based)?
    It seems that none of you have mentioned that operator[] in C++ can be overloaded. By overloading operator[], it's possible to write a class whose instances can simulate 1-based arrays on syntax level. A good optimizing compiler would in-line the index adjustment and produce very efficient code.
    One time, I had to work with C++ code ported from FORTRAN, and got an array out of bounds error because of this (loop over 1 to 4 instead of 0 to 3).
    Wouldn't it be faster and less error-prone to write a partial FORTRAN-to-C++ compiler? You don't have to support all FORTRAN features. You only need those that you've used. :)
  • required (unregistered)

    Typical Apple Computer murder.

Leave a comment on “It's CAD-tastic!”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article