Sizes of pointers

Discussion in 'C Programming' started by James Harris \(es\), Jul 30, 2013.

  1. (snip on CPU and I/O speeds, then I wrote)
    There are two ways to do sequential I/O for OS/360 (and they are
    still there in z/OS), which differ in how much the OS does for you.

    For BSAM, (Basic Sequential Access Method) you pretty much do it AIO
    like with READ and WAIT macros. For double buffering, you start
    with two READs, then loop processing one while the other is read,
    and with the appropriate WAIT at the end (or start) of the loop.

    For QSAM (Queued Sequential Access Method) the OS does most of
    keeping track of buffers, and, I believe, properly processing
    more than two. QSAM also does blocking and deblocking for you.
    For OS/360, and random access, you have BDAM, and the records are
    unblocked. (You can put anything in the records you want, but
    they are unblocked as seen by the system.) That is, the records,
    of whatever size you want from 1 byte to the size of a disk track,
    are physical blocks on the disk. (For people used to unix, think
    of blocks on tape.) The disk hardware can then find and supply
    the appropriate disk block.

    -- glen
     
    glen herrmannsfeldt, Aug 8, 2013
    1. Advertisements

  2. James Harris \(es\)

    Tim Rentsch Guest

    This is all just circular reasoning - it's a sign bit
    because what's being done is sign extension, and it's
    sign extension because what's being "extended" is a
    sign bit. It's just as consistent to say the smaller
    address space is mapped to the larger address space
    by replicating the high order bit. The addresses
    themselves have no intrinsic signedness - only which
    point of view one takes might ascribe one.
     
    Tim Rentsch, Aug 8, 2013
    1. Advertisements

  3. Not exactly. An implementation that uses a 2's-complement
    representation for signed integers *can* use the same instructions for
    signed vs. unsigned addition, subtraction, and multiplication, because
    the behavior of signed overflow is undefined.
    Would you really? And what do you think would happen if you tried to
    apply the "%" operator to a pointer value?

    [...]
    Thank you for not using your one-letter macros. I'm still not going to
    try to figure out what your program does.

    [snip]
     
    Keith Thompson, Aug 8, 2013
  4. The point is that sign-extension is a simple way to describe the
    replication of the high order bit. I don't think anyone is arguing that
    pointers on such a system *must* be described as (or as behaving like)
    signed integers, merely that they can reasonably be described that way.
     
    Keith Thompson, Aug 8, 2013
  5. James Harris \(es\)

    Lew Pitcher Guest

    Perhaps. Perhaps not. Keith has purpose in asking his question.

    First off, only a subset of mathematical and logical operations are valid
    when applied against a pointer, and modulo (%) is not one of those
    operations. Your
    example address % 8
    example would not be legal C.

    Having said that, your conclusions (above) are also faulty. Assuming that,
    by slight-of-programmers-hand, you could take the modulo of a pointer, you
    would find that
    short int are not always aligned on 2-byte boundaries
    int are not always aligned on 4-byte boundaries
    float are not always aligned on 8-byte boundaries

    Alignment issues depend on the implementation and the platform. For
    instance, on some platforms, 1-byte alignment is legal (but, not
    necessarily efficient) for /all/ integral variables. For some platforms,
    short and int must be 4-byte aligned. It depends on the hardware and the
    compiler.

    BTW, you can't take modulo of a pointer, but you /can/ convert a pointer to
    an integer, and take modulo of that value. There's no guarantee that the
    conversion will make much sense; the result is "implementation defined",
    according to the C standard.

    HTH
     
    Lew Pitcher, Aug 8, 2013
  6. You are mistaken. The result would be an error message from the
    compiler. C doesn't define the "%" operator for pointers.

    If you're talking about something other than C, you're in the wrong
    place.
     
    Keith Thompson, Aug 8, 2013
  7. James Harris \(es\)

    Tim Rentsch Guest

    You're confusing abstract machines and implementations.
    Obviously a Java implementation could be done that would run
    C-to-JVM-compiled code as fast as native C code, by JIT
    compiling into equivalent native code. There is nothing
    in the JVM definition that would prevent this. If anything,
    using a single memory to "fake" a C address space might help
    the effort.

    To put this another way, your thesis is disproved by the
    existence of high performance implementations of the 80x86
    architecture - a truly awful abstract machine, but still
    capable of high performance implementation.
     
    Tim Rentsch, Aug 9, 2013
  8. James Harris \(es\)

    Tim Rentsch Guest

    Please see my response to Malcolm McLean's post regarding
    confusing abstract machines and implementations.
     
    Tim Rentsch, Aug 9, 2013
  9. James Harris \(es\)

    Tim Rentsch Guest

    As I mentioned in another posting, just because the address
    spaces are (conceptually) separate, there is no reason a
    single address representation couldn't allow addressing
    memory in either space. There are lots of different ways
    this might be done; using a particular bit to distinguish
    "user space" and "kernel space" is one obvious way.
     
    Tim Rentsch, Aug 9, 2013
  10. James Harris \(es\)

    Tim Rentsch Guest

    I read through this posting but am not sure what point you
    were trying to make. It sounds like you agree with my
    basic point that whether pointers on x86-64 are signed is
    more a matter of subjective perception than objective
    reality. I understand and agree with your view that
    thinking of pointers as signed is convenient in some
    ways. If we do indeed have agreement on these two
    basic points then I am satisfied with the discussion.
     
    Tim Rentsch, Aug 9, 2013
  11. James Harris \(es\)

    Tim Rentsch Guest

    I don't share this opinion. If the inventors said that some values
    were red and other values were green, that doesn't mean the values
    necessarily acquire the property of being colored. Certainly it is
    what they said (at least I will assume so for the sake of the
    discussion), but that's not the property I'm interested in when
    talking about signedness.

    The reason appeal to authority is not valid, or more accurately
    relevant, for what I'm saying is that the property I'm concerned
    with is not legislated by any authority.
    Are you now saying the documentation does NOT describe the
    transformation as sign extension? So we have a different authority
    saying something different? For the property I've been talking
    about, it doesn't matter whether the instruction is called
    Sign Extend, Arithmetic Shift, Replicate High bit, Adjust
    Pointer Size, or anything else -- what matters how things
    behave, not what they are called.
    Is that so? Just what physical equipment do you have in mind to
    measure the simplicity, elegance, and self-consistency of a point
    of view, to back up your claim?
    Your idea of objective truth and mine apparently are not identical.
     
    Tim Rentsch, Aug 9, 2013
  12. James Harris \(es\)

    Tim Rentsch Guest

    I'm happy to agree that it's reasonable to describe how x86-64
    pointers work using sign extension, etc, if others are willing to
    agree that it's equally reasonable to describe how those pointers
    work without using sign extension, etc. In short, I think what
    you're saying is pretty much the same as what I'm saying... but
    I'm not sure that other people in the discussion agree on that.
     
    Tim Rentsch, Aug 9, 2013
  13. I might even say more reasonable, but less convenient.

    Reminds me of the ways PL/I and (newer) Fortran pass arrays.
    (being an addressing question, it might be applicable).

    Both languages allow one to declare arrays giving lower and
    upper bounds for dimensions. For PL/I, when passed to a called
    procedure, the bounds information is also passed, both lower
    and upper bound.

    With Fortran assumed shape, where dimension information is
    passed to a called routine, only the extent is passed.
    (As seen in the called routine, the origin is 1, by default,
    or can be specified other than 1.)

    The former seems more natural, but the latter is sometimes more
    convenient, especially when rewriting old routines.

    They are both reasonably, but I don't know that you can say equally
    reasonable. (As with addressing, it is difficult to measure
    reasonableness.)

    -- glen
     
    glen herrmannsfeldt, Aug 9, 2013
  14. OK, how about something else that people like to disagree on,
    and that is bit numbering. While endianness of many processors
    is fixed by design, on most the numbering of bits within bytes
    is not physically part of the hardware. It is, however, often
    part of the documentation for the hardware.

    Some people might like a different numbering than that in the
    documentation, but doing so will result in confusion. That said,
    using different numbering is still confusing when interfacing
    between different systems. (I once knew someone using an Intel UART
    in an Apple II, and, after wiring it up noticed the different
    bit numbering conventions.)

    Now, the authority could require a specific notation as part of
    the license or other agreement. (SPARC, for example, requires their
    trademark to be in bold font.)
    If the authority isn't reasonable, then people won't follow it.
    (Colored bits might not be reasonable.) If it is reasonable and
    consistent, though, it will often be followed.

    By the way, the index registers on the IBM 704 and successors
    subtract from the base address, and arrays on such machines are
    usually implemented in decreasing address order. Note that unlike
    the signedness convention this one has physical meaning.

    -- glen
     
    glen herrmannsfeldt, Aug 9, 2013
  15. James Harris \(es\)

    James Kuyper Guest

    It could be both - after diagnosing the code, the implementation is free
    to translate it into a program that, if executed, does precisely what he
    expects it to do. The implementation is also free to translate it into a
    program that plays "Killing Me Softly With His Song". Both possible
    results are, of course, equally relevant to the issue he's talking about.
     
    James Kuyper, Aug 9, 2013
  16. (snip, I wrote)
    I thought 2314's were 3600, but that is remembering from a long
    time ago. According to:

    http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.31.3058&
    rep=rep1&type=pdf&ei=T8AEUtDBMeKQyQH1qIDYDA&usg=AFQjCNF7VPXvj_a
    mFEyNtSpfiRNIXj9gQg&bvm=bv.50500085,d.aWc

    it is 3600, but I don't have any official references.

    It seems that the 2305, designed for S/360, but more commonly used
    for S/370, is 10000RPM.

    I believe the 2301 is 3600RPM.

    OK, now I found a reference that says 2400RPM for 2314.

    -- glen
     
    glen herrmannsfeldt, Aug 9, 2013
  17. James Harris \(es\)

    Lew Pitcher Guest

    No. YOU claim that I claimed the above. I said no such thing. Reread what I
    wrote, and learn.
    I don't understand your question. Perhaps you need to rephrase it.

    If you are referring to how the C compiler and runtime requires pointers (to
    various data types) aligned, that's something that you have to check
    against the specific compiler & runtime. There is no general rule for
    alignment that applies to *all* C compilers and *all* C runtime.

    If you are referring to how the C code of an application program can
    establish proper alignment of pointers, then there's a simple answer: A C
    application should not attempt to *explicitly* determine alignment.
    Instead, it should depend on the C language to do that for it. malloc()ed
    memory is guaranteed (by the C standard) to be allocated such that it suits
    any system/compiler/runtime-imposed alignment requirements. Structures are
    guaranteed (by the C standard) to properly enforce alignment rules between
    elements. Unions do not (IIRC) "enforce" alignment, but do /expect/ that
    all alternative elements "behave" as far as alignment goes. Thus, for
    single elements, you malloc() and map the results either to a pointer to a
    simple data item (such as an int or char or float) or to a pointer to a
    structure or to a pointer to a union.

    OTOH, if you are building your own memory allocator, and want to enforce the
    alignment requirements of /your specific platform/, then you have diverted
    into the area of "implementation specific" or "undefined" behaviour, and
    are no longer writing C standard-compliant C code. That's a risk you have
    to evaluate and take (or not) as you see fit.

    As for the mathematics of pointer arithmetic, their definition in the C
    language has nothing to do with me. I make no claims on the validity or
    appropriateness of the restrictions of pointer arithmetic in C. That's what
    the C standard defines. If you don't like the rules, complain (and give
    alternatives) to the ISO C standards body. Be prepared to defend your
    requirements and proposal.
     
    Lew Pitcher, Aug 9, 2013
  18. James Harris \(es\)

    James Kuyper Guest

    On 08/09/2013 11:35 AM, Lew Pitcher wrote:
    ....
    That was true in C99, but C2011 has added max_align_t, _Alignof() and
    _Alignas(), which means it's now possible to accommodate
    implementation-specific alignments with portable C code. Well, "now"
    meaning as soon as you can find a compiler that implements those features.
     
    James Kuyper, Aug 9, 2013
  19. James Harris \(es\)

    Lew Pitcher Guest

    Thanks, James

    I learn something new every day. I'll have to get me a copy of the 2011
    standard and read it asap :)

    Luck be with you
     
    Lew Pitcher, Aug 9, 2013
  20. There is an efficiency issue.

    Say we're storing binary "objects" in a hash table or similar. Most of
    the time these objects are going to be integers, pointers, reals, only rarely
    char arrays. But we won't want to complicate the interface with a rule
    that types have to be specified explicitly.
    By detecting alignment, we can treat the chars specially, and use fast
    instructions to manipulate the bulk of the usage cases.
     
    Malcolm McLean, Aug 9, 2013
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.