Re: I think this is a disadvantag

Discussion in 'C Programming' started by Xavier Roche, Jun 15, 2013.

  1. Xavier Roche

    Xavier Roche Guest

    Le 15/06/2013 14:24, paskali a écrit :
    > int sum(int num) {
    > return sum;


    You are returning a function (pointer) of a function taking an integer,
    and returning an integer, casted to an integer. Except the implicit
    cast, and the possible loss of data (the function pointer might have a
    larger size than the integer), this is perfectly valid C (ugly, but valid).

    It could be written as something like:
    return (int) (int (*)(int)) sum;

    If you compile this program with gcc, you should get some warning
    telling you that something fishy is going on:
    1.c:3:5: warning: return makes integer from pointer without a cast
    [enabled by default]
    Xavier Roche, Jun 15, 2013
    #1
    1. Advertising

  2. Xavier Roche

    Xavier Roche Guest

    Le 15/06/2013 15:34, paskali a écrit :
    > sum += num[c];


    You are trying to increment a function pointer, which can not be
    modified (constant). The two "sum" symbols share the same namespace, you
    have to use another name.
    Xavier Roche, Jun 15, 2013
    #2
    1. Advertising

  3. Xavier Roche

    James Kuyper Guest

    On 06/15/2013 08:46 AM, Xavier Roche wrote:
    > Le 15/06/2013 14:24, paskali a �crit :
    >> int sum(int num) {
    >> return sum;

    >
    > You are returning a function (pointer) of a function taking an integer,
    > and returning an integer, casted to an integer. Except the implicit
    > cast, and the possible loss of data (the function pointer might have a
    > larger size than the integer), this is perfectly valid C (ugly, but valid).
    >
    > It could be written as something like:
    > return (int) (int (*)(int)) sum;
    >
    > If you compile this program with gcc, you should get some warning
    > telling you that something fishy is going on:
    > 1.c:3:5: warning: return makes integer from pointer without a cast
    > [enabled by default]


    I've used languages (I can't remember which ones, right now) where a
    function definition like the following:

    int sum(int num)
    {
    while(num-->0)
    sum += num;
    }

    Was equivalent to the following C code:

    int sum(int num)
    {
    int sum = 0; // Declaration hides function declaration
    while(num-->0)
    sum += num;
    return sum;
    }

    In other words, there was an implicit definition of a local variable
    with the same name as the function, with a type matching the return type
    of the function, and an implicit return of the value of that value upon
    exiting the function. Perhaps he's used such languages, and doesn't
    understand how to do the equivalent thing in C?
    --
    James Kuyper
    James Kuyper, Jun 15, 2013
    #3
  4. On 15-Jun-13 12:51, James Kuyper wrote:
    > I've used languages (I can't remember which ones, right now) where a
    > function definition like the following:
    >
    > int sum(int num)
    > {
    > while(num-->0)
    > sum += num;
    > }
    >
    > Was equivalent to the following C code:
    >
    > int sum(int num)
    > {
    > int sum = 0; // Declaration hides function declaration
    > while(num-->0)
    > sum += num;
    > return sum;
    > }
    >
    > In other words, there was an implicit definition of a local variable
    > with the same name as the function, with a type matching the return
    > type of the function, and an implicit return of the value of that
    > value upon exiting the function.


    IIRC, that's how Visual Basic functions work. I don't recall seeing
    that construct in any other language.

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
    Stephen Sprunk, Jun 15, 2013
    #4
  5. Xavier Roche

    James Kuyper Guest

    On 06/15/2013 04:29 PM, Robert Wessel wrote:
    > On Sat, 15 Jun 2013 15:08:14 -0500, Stephen Sprunk
    > <> wrote:
    >
    >> On 15-Jun-13 12:51, James Kuyper wrote:
    >>> I've used languages (I can't remember which ones, right now) where a
    >>> function definition like the following:
    >>>
    >>> int sum(int num)
    >>> {
    >>> while(num-->0)
    >>> sum += num;
    >>> }
    >>>
    >>> Was equivalent to the following C code:
    >>>
    >>> int sum(int num)
    >>> {
    >>> int sum = 0; // Declaration hides function declaration
    >>> while(num-->0)
    >>> sum += num;
    >>> return sum;
    >>> }
    >>>
    >>> In other words, there was an implicit definition of a local variable
    >>> with the same name as the function, with a type matching the return
    >>> type of the function, and an implicit return of the value of that
    >>> value upon exiting the function.

    >>
    >> IIRC, that's how Visual Basic functions work. I don't recall seeing
    >> that construct in any other language.


    I've written BASIC code, but that was 35 years ago. I think that was
    before it evolved into VB.

    > Fortran, Pascal...


    I thought it was Fortran I was remembering, but it's been a quarter
    century since the last time I did any serious Fortran programming, so I
    wasn't sure.
    --
    James Kuyper
    James Kuyper, Jun 15, 2013
    #5
  6. Xavier Roche <> writes:
    > Le 15/06/2013 14:24, paskali a écrit :
    >> int sum(int num) {
    >> return sum;

    >
    > You are returning a function (pointer) of a function taking an integer,
    > and returning an integer, casted to an integer. Except the implicit
    > cast, and the possible loss of data (the function pointer might have a
    > larger size than the integer), this is perfectly valid C (ugly, but valid).


    No, it's not valid C. The name "sum" does refer to the function, but
    there is no implicit conversion from pointer types to integer types.
    (Note "implicit conversion", not "implicit cast"; a cast is by
    definition an explicit conversion, specified by a cast operator,
    a type name in parentheses.)

    > It could be written as something like:
    > return (int) (int (*)(int)) sum;


    There's no need for the inner cast; sum is already of type int(*)(int)
    (after the implicit conversion from function to pointer-to-function_).

    The outer cast has undefined behavior (by omission, because the standard
    doesn't define the behavior of a conversion of a function pointer to an
    integer).

    > If you compile this program with gcc, you should get some warning
    > telling you that something fishy is going on:
    > 1.c:3:5: warning: return makes integer from pointer without a cast
    > [enabled by default]


    And IMHO this should be a fatal error, not just a warning. It's a
    constraint violation. (A mere warning satisfies the standard's
    requirement for a diagnostic, but I personally dislike gcc's default
    laxity.)

    In any case, I can't think of any good reason to write code like that,
    unless it's to discuss why one shouldn't write code like that.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 16, 2013
    #6
  7. Xavier Roche

    Xavier Roche Guest

    Le 16/06/2013 01:19, Keith Thompson a écrit :
    >> If you compile this program with gcc, you should get some warning
    >> telling you that something fishy is going on:
    >> 1.c:3:5: warning: return makes integer from pointer without a cast
    >> [enabled by default]

    >
    > And IMHO this should be a fatal error, not just a warning.


    Old code probably is using that (ie. casting a function pointer to a
    32-bit int). uintptr_t is a rather "recent" (cough cough) addition.
    Xavier Roche, Jun 16, 2013
    #7
  8. Xavier Roche

    Tim Rentsch Guest

    James Kuyper <> writes:

    > On 06/15/2013 04:29 PM, Robert Wessel wrote:
    >>> [snip]

    >>
    >> Fortran, Pascal...

    >
    > I thought it was Fortran I was remembering, but it's been a
    > quarter century since the last time I did any serious Fortran
    > programming, so I wasn't sure.


    If it was really at least 25 years ago, the programming was in
    FORTRAN, not Fortran. FORTRAN didn't become Fortran until the
    1991 version of its standard (ISO/IEC standard 1539:1991).
    Tim Rentsch, Jun 16, 2013
    #8
  9. Xavier Roche

    Tim Rentsch Guest

    Keith Thompson <> writes:

    > Xavier Roche <> writes:
    >> Le 15/06/2013 14:24, paskali a @C3{A9}crit :
    >>> int sum(int num) {
    >>> return sum;

    >>
    >> You are returning a function (pointer) of a function taking an integer,
    >> and returning an integer, casted to an integer. Except the implicit
    >> cast, and the possible loss of data (the function pointer might have a
    >> larger size than the integer), this is perfectly valid C (ugly, but valid).

    >
    > No, it's not valid C. The name "sum" does refer to the function, but
    > there is no implicit conversion from pointer types to integer types.
    > (Note "implicit conversion", not "implicit cast"; a cast is by
    > definition an explicit conversion, specified by a cast operator,
    > a type name in parentheses.)
    >
    >> It could be written as something like:
    >> return (int) (int (*)(int)) sum;

    >
    > There's no need for the inner cast; sum is already of type int(*)(int)
    > (after the implicit conversion from function to pointer-to-function_).
    >
    > The outer cast has undefined behavior (by omission, because the standard
    > doesn't define the behavior of a conversion of a function pointer to an
    > integer).


    Not that I want to disagree, but how do you reconcile that statement
    with 6.3.2.3 p6?

    Any pointer type may be converted to an integer type. Except
    as previously specified, the result is implementation-defined.
    Tim Rentsch, Jun 16, 2013
    #9
  10. Xavier Roche

    Geoff Guest

    On Sun, 16 Jun 2013 06:56:50 -0700, Tim Rentsch
    <> wrote:

    >James Kuyper <> writes:
    >
    >> On 06/15/2013 04:29 PM, Robert Wessel wrote:
    >>>> [snip]
    >>>
    >>> Fortran, Pascal...

    >>
    >> I thought it was Fortran I was remembering, but it's been a
    >> quarter century since the last time I did any serious Fortran
    >> programming, so I wasn't sure.

    >
    >If it was really at least 25 years ago, the programming was in
    >FORTRAN, not Fortran. FORTRAN didn't become Fortran until the
    >1991 version of its standard (ISO/IEC standard 1539:1991).


    FORTRAN didn't need a standard to change it's capitalization any more
    than LASER or RADAR need a standard to become laser or radar. Acronyms
    such as these succumb to common usage, not some standardization
    document that was probably following the historical usage and not
    leading it.
    Geoff, Jun 16, 2013
    #10
  11. Xavier Roche

    Tim Rentsch Guest

    Geoff <> writes:

    > On Sun, 16 Jun 2013 06:56:50 -0700, Tim Rentsch
    > <> wrote:
    >
    >>James Kuyper <> writes:
    >>
    >>> On 06/15/2013 04:29 PM, Robert Wessel wrote:
    >>>>> [snip]
    >>>>
    >>>> Fortran, Pascal...
    >>>
    >>> I thought it was Fortran I was remembering, but it's been a
    >>> quarter century since the last time I did any serious Fortran
    >>> programming, so I wasn't sure.

    >>
    >>If it was really at least 25 years ago, the programming was in
    >>FORTRAN, not Fortran. FORTRAN didn't become Fortran until the
    >>1991 version of its standard (ISO/IEC standard 1539:1991).

    >
    > FORTRAN didn't need a standard to change it's capitalization
    > any more than LASER or RADAR need a standard to become laser or
    > radar. Acronyms such as these succumb to common usage, not
    > some standardization document that was probably following the
    > historical usage and not leading it.


    The difference is laser and radar are not defined by an official
    standards document. Fortran is (and FORTRAN was). Fortran and
    FORTRAN are different languages, just as C99 and C90 are different
    languages.
    Tim Rentsch, Jun 16, 2013
    #11
  12. Xavier Roche

    Geoff Guest

    On Sun, 16 Jun 2013 10:38:55 -0700, Tim Rentsch
    <> wrote:

    >Geoff <> writes:
    >
    >> On Sun, 16 Jun 2013 06:56:50 -0700, Tim Rentsch
    >> <> wrote:
    >>
    >>>James Kuyper <> writes:
    >>>
    >>>> On 06/15/2013 04:29 PM, Robert Wessel wrote:
    >>>>>> [snip]
    >>>>>
    >>>>> Fortran, Pascal...
    >>>>
    >>>> I thought it was Fortran I was remembering, but it's been a
    >>>> quarter century since the last time I did any serious Fortran
    >>>> programming, so I wasn't sure.
    >>>
    >>>If it was really at least 25 years ago, the programming was in
    >>>FORTRAN, not Fortran. FORTRAN didn't become Fortran until the
    >>>1991 version of its standard (ISO/IEC standard 1539:1991).

    >>
    >> FORTRAN didn't need a standard to change it's capitalization
    >> any more than LASER or RADAR need a standard to become laser or
    >> radar. Acronyms such as these succumb to common usage, not
    >> some standardization document that was probably following the
    >> historical usage and not leading it.

    >
    >The difference is laser and radar are not defined by an official
    >standards document. Fortran is (and FORTRAN was). Fortran and
    >FORTRAN are different languages, just as C99 and C90 are different
    >languages.


    They are not different languages, they are different dialects of the
    same language. Just as natural languages evolve so do computer
    languages, albeit by way of a formal process.

    I'll say it again, the standard wasn't leading the usage, it was
    caving into it.
    Geoff, Jun 16, 2013
    #12
  13. Xavier Roche

    BartC Guest

    "Tim Rentsch" <> wrote in message
    news:...
    > Geoff <> writes:
    >> FORTRAN didn't need a standard to change it's capitalization
    >> any more than LASER or RADAR need a standard to become laser or
    >> radar. Acronyms such as these succumb to common usage, not
    >> some standardization document that was probably following the
    >> historical usage and not leading it.

    >
    > The difference is laser and radar are not defined by an official
    > standards document. Fortran is (and FORTRAN was). Fortran and
    > FORTRAN are different languages, just as C99 and C90 are different
    > languages.


    Isn't Fortran case-insensitive? In that case it would be odd for it to
    matter whether you write Fortran or FORTRAN. A version number should be used
    if it's important to know exactly which revision of the language is being
    discussed.

    --
    Bartc
    BartC, Jun 16, 2013
    #13
  14. Xavier Roche <> writes:
    > Le 16/06/2013 01:19, Keith Thompson a écrit :
    >>> If you compile this program with gcc, you should get some warning
    >>> telling you that something fishy is going on:
    >>> 1.c:3:5: warning: return makes integer from pointer without a cast
    >>> [enabled by default]

    >>
    >> And IMHO this should be a fatal error, not just a warning.

    >
    > Old code probably is using that (ie. casting a function pointer to a
    > 32-bit int). uintptr_t is a rather "recent" (cough cough) addition.


    The code in question is not *casting* a function pointer to an
    integer. It's *returning* a function pointer value from a function
    with int as its return type.

    If you want to convert a pointer to an integer, you need to use an
    explicit cast -- and uintptr_t, if your implementation supports it,
    is probably the most sensible integer type to use.

    My annoyance with gcc is that, by default, it responds to the
    constraint violation of attempting to convert a pointer to an integer
    without a cast by issuing a warning rather than an error message.
    (It's easy enough to turn it into an error with "-pedantic-errors",
    but the fact that it's an extra step means a lot of people don't
    bother, and bad code isn't caught.)

    But there is no defined behavior for converting a function pointer
    to an integer (unless you're relying on guarantees outside the C
    standard; I think POSIX defines the behavior).

    In any case, the code in question did not *deliberately* attempt
    to convert a pointer to an integer. It was the result of a
    misunderstanding of the visibility rules.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 16, 2013
    #14
  15. Xavier Roche

    James Kuyper Guest

    On 06/16/2013 12:25 PM, Geoff wrote:
    > On Sun, 16 Jun 2013 06:56:50 -0700, Tim Rentsch
    > <> wrote:
    >
    >> James Kuyper <> writes:
    >>
    >>> On 06/15/2013 04:29 PM, Robert Wessel wrote:
    >>>>> [snip]
    >>>>
    >>>> Fortran, Pascal...
    >>>
    >>> I thought it was Fortran I was remembering, but it's been a
    >>> quarter century since the last time I did any serious Fortran
    >>> programming, so I wasn't sure.

    >>
    >> If it was really at least 25 years ago, the programming was in
    >> FORTRAN, not Fortran. FORTRAN didn't become Fortran until the
    >> 1991 version of its standard (ISO/IEC standard 1539:1991).

    >
    > FORTRAN didn't need a standard to change it's capitalization any more
    > than LASER or RADAR need a standard to become laser or radar. Acronyms
    > such as these succumb to common usage, not some standardization
    > document that was probably following the historical usage and not
    > leading it.


    FORTRAN I (sic) was the very first programming language I learned, in
    high school, around 1976. I programmed FORTRAN IV from 1978-80, and in
    VMS Fortran during 1988-89. VMS Fortran was very distinctly
    non-standard, and AFAICT, it was seldom fully capitalized, so I'll stand
    by the capitalization I originally used.
    --
    James Kuyper
    James Kuyper, Jun 16, 2013
    #15
  16. Xavier Roche

    Eric Sosman Guest

    [OT] Re: I think this is a disadvantag

    On 6/16/2013 4:49 PM, James Kuyper wrote:
    > [...]
    > FORTRAN I (sic) was the very first programming language I learned, in
    > high school, around 1976. [...]


    The time line is surprising. In 1966, a full decade earlier,
    *my* first programming language was FORTRAN II (which Wikipedia
    says had been around since 1958), and by 1968 I'd moved on to
    FORTRAN IV (genesis 1962).

    What a very backward school you went to, James! :)

    --
    Eric Sosman
    d
    Eric Sosman, Jun 16, 2013
    #16
  17. Tim Rentsch <> writes:
    > Keith Thompson <> writes:

    [...]
    >> The outer cast has undefined behavior (by omission, because the standard
    >> doesn't define the behavior of a conversion of a function pointer to an
    >> integer).

    >
    > Not that I want to disagree, but how do you reconcile that statement
    > with 6.3.2.3 p6?
    >
    > Any pointer type may be converted to an integer type. Except
    > as previously specified, the result is implementation-defined.


    I don't. I was mistaken. (And if you don't want to disagree, I'd like
    to see an argument that I was right in the first place; I don't think I
    was.)

    Here's the full paragraph:

    Any pointer type may be converted to an integer type. Except as
    previously specified, the result is implementation-defined. If
    the result cannot be represented in the integer type, the
    behavior is undefined. The result need not be in the range of
    values of any integer type.

    C99 and C11 have the same wording. C90 says something similar, but it's
    under the description of the cast operator:

    A pointer may be converted to an integral type. The size of integer
    required and the result are implementation-defined. If the space
    provided is not long enough, the behavior is undefined.

    (Note that C90 was a bit more vague; it talks about the "space
    provided" rather than the range of values.)

    So the rules for pointer-to-integer conversion make no distinction
    between pointers to object types and pointers to function types.
    If the result of the conversion is within the range of the
    target integer type, the result is implementation-defined (and,
    says a non-normative footnote, "intended to be consistent with the
    addressing structure of the execution environment"). If the result
    is not within that range, the behavior is undefined.

    For object pointer types, you can portably avoid undefined behavior
    by using uintptr_t as the target type (after checking whether
    UINTPTR_MAX is defined). For function pointer types, you can't;
    you have to rely on guarantees outside the C standard.

    The source of my confusion was the fact that the behavior of a
    conversion from an object pointer type to a function pointer type,
    or vice versa, is undefined by omission (except for the special case
    of a null pointer) (unless I'm missing something else). I managed
    to incorrectly conflate that with pointer/integer conversions.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 16, 2013
    #17
  18. Xavier Roche

    James Kuyper Guest

    Re: [OT] Re: I think this is a disadvantag

    On 06/16/2013 05:20 PM, Eric Sosman wrote:
    > On 6/16/2013 4:49 PM, James Kuyper wrote:
    >> [...]
    >> FORTRAN I (sic) was the very first programming language I learned, in
    >> high school, around 1976. [...]

    >
    > The time line is surprising. In 1966, a full decade earlier,
    > *my* first programming language was FORTRAN II (which Wikipedia
    > says had been around since 1958), and by 1968 I'd moved on to
    > FORTRAN IV (genesis 1962).
    >
    > What a very backward school you went to, James! :)


    Most high schools didn't have computer programming courses at all at
    that time. The only reason mine did was that an alumnus had donated to
    the school an IBM 1620 machine that was already long obsolete at the
    time of the donation. It had no display, just a teletype terminal, and
    20KB magnetic core RAM. It had no operating system, a punched card
    reader, a keypunch machine, and a card sorting machine. It had no
    built-in capability to perform multiplication - part of the start-up
    card deck that we had to load into it before compiling and running our
    programs was a base-10 multiplication table.
    --
    James Kuyper
    James Kuyper, Jun 17, 2013
    #18
  19. Xavier Roche

    Geoff Guest

    On Sun, 16 Jun 2013 16:49:39 -0400, James Kuyper
    <> wrote:

    >On 06/16/2013 12:25 PM, Geoff wrote:
    >> On Sun, 16 Jun 2013 06:56:50 -0700, Tim Rentsch
    >> <> wrote:
    >>
    >>> James Kuyper <> writes:
    >>>
    >>>> On 06/15/2013 04:29 PM, Robert Wessel wrote:
    >>>>>> [snip]
    >>>>>
    >>>>> Fortran, Pascal...
    >>>>
    >>>> I thought it was Fortran I was remembering, but it's been a
    >>>> quarter century since the last time I did any serious Fortran
    >>>> programming, so I wasn't sure.
    >>>
    >>> If it was really at least 25 years ago, the programming was in
    >>> FORTRAN, not Fortran. FORTRAN didn't become Fortran until the
    >>> 1991 version of its standard (ISO/IEC standard 1539:1991).

    >>
    >> FORTRAN didn't need a standard to change it's capitalization any more
    >> than LASER or RADAR need a standard to become laser or radar. Acronyms
    >> such as these succumb to common usage, not some standardization
    >> document that was probably following the historical usage and not
    >> leading it.

    >
    >FORTRAN I (sic) was the very first programming language I learned, in
    >high school, around 1976. I programmed FORTRAN IV from 1978-80, and in
    >VMS Fortran during 1988-89. VMS Fortran was very distinctly
    >non-standard, and AFAICT, it was seldom fully capitalized, so I'll stand
    >by the capitalization I originally used.


    The Fortran (no version) I learned in college in 1973-76 was very much
    non-standard and ran on an Interdata Model IV with 8 users. We used
    Teletype model 33 KSRs and they had no lower case. FORTRAN was
    FORTRAN. I think the invocation of the compiler was FC. I know it was
    interactive for small programs but 4k of core per user meant larger
    program sources had to be input from 8-channel paper tape and compiled
    and the binaries were punched and loaded from the KSR. As I recall
    typing FC called the compiler and it expected the tape to be queued in
    the reader. In interactive mode you invoked an editor and typed in
    your program. Once you had it "working" you punched the source to tape
    for the next session.

    I can still remember the nerd at the next terminal holding up a copy
    of Popular Electronics with the MITS-Altair 8800 on the cover and
    saying "This is the future." "Real Programmers" did it with toggle
    switches. I can still remember toggling in BIN loaders on PDP-8e's in
    1979.

    By the late 70's FORTRAN was Fortran in common usage by my peers at
    the time. By 1984 I was at IBM talking to systems guys who were having
    trouble with an APT 360 source that wouldn't link-edit because of
    compatibility problems with their version of the Fortran compiler. I
    can't remember whether FORTRAN was Fortran by then but it made no
    difference to us at the time.
    Geoff, Jun 17, 2013
    #19
  20. Xavier Roche

    Eric Sosman Guest

    Re: [OT] Re: I think this is a disadvantag

    On 6/16/2013 7:49 PM, James Kuyper wrote:
    > On 06/16/2013 05:20 PM, Eric Sosman wrote:
    >> On 6/16/2013 4:49 PM, James Kuyper wrote:
    >>> [...]
    >>> FORTRAN I (sic) was the very first programming language I learned, in
    >>> high school, around 1976. [...]

    >>
    >> The time line is surprising. In 1966, a full decade earlier,
    >> *my* first programming language was FORTRAN II (which Wikipedia
    >> says had been around since 1958), and by 1968 I'd moved on to
    >> FORTRAN IV (genesis 1962).
    >>
    >> What a very backward school you went to, James! :)

    >
    > Most high schools didn't have computer programming courses at all at
    > that time. The only reason mine did was that an alumnus had donated to
    > the school an IBM 1620 machine that was already long obsolete at the
    > time of the donation. It had no display, just a teletype terminal, and
    > 20KB magnetic core RAM. It had no operating system, a punched card
    > reader, a keypunch machine, and a card sorting machine. It had no
    > built-in capability to perform multiplication - part of the start-up
    > card deck that we had to load into it before compiling and running our
    > programs was a base-10 multiplication table.


    A-a-a-a-h, yer takin' me back. Not only was the 1620 unable
    to multiply and divide in circuitry, but it couldn't even add or
    subtract without a table pre-loaded in dedicated memory. Hence
    its nickname of CADET: Can't Add, Doesn't Even Try.

    Decimal computer, "Ooh, how primitive." On the other hand, it
    was dead easy to do multiple-precision arithmetic: twenty-digit,
    fifty-digit, hundred-digit numbers, you used the exact same
    instructions as for five-digit quantities. Not bad ...

    Still, it's a bit startling that you were using original
    FORTRAN (probably not "FORTRAN I") on the 1620. I'd used FORTRAN II
    on that machine a decade before you encountered it, and it's strange
    that you didn't have access to the "more modern" compiler.

    A few years ago I visited the Computer History Museum in its
    new location in Mountain View, California. In a back room they had
    the carcase of a 1620 undergoing restoration -- or "simulation,"
    really, because the core memory had long since turned to dust and
    IBM had informed the museum that the art of making core was lost,
    so the restorers would have to fake it with semiconductors. Brought
    back old memories anyhow: Does "4900796" mean anything to you?

    --
    Eric Sosman
    d
    Eric Sosman, Jun 17, 2013
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Preben Holm
    Replies:
    2
    Views:
    560
    Preben Holm
    Apr 28, 2005
  2. Replies:
    0
    Views:
    599
  3. Replies:
    1
    Views:
    865
    Jack Klein
    Apr 13, 2005
  4. David Mark
    Replies:
    17
    Views:
    235
    David Mark
    Mar 23, 2010
  5. Keith Thompson

    Re: I think this is a disadvantag

    Keith Thompson, Jun 16, 2013, in forum: C Programming
    Replies:
    0
    Views:
    207
    Keith Thompson
    Jun 16, 2013
Loading...

Share This Page