1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Re: An idea how to speed up computer programs and avoid waiting.("event driven memory system")

Discussion in 'Nvidia' started by Muscipula, Sep 13, 2011.

  1. Muscipula

    Muscipula Guest

    The only way you can modify the IP - apart from a branch etc - is to
    change the return address on the stack. This can be useful if you want
    to read embedded data that is placed directly after the instruction to
    the call. Fo example you can pass on a null
    terminated string

    Andrew Sprott
    Muscipula, Sep 13, 2011
    #1
    1. Advertising

  2. Re: An idea how to speed up computer programs and avoid waiting. ("event driven memory system")

    On Fri, 16 Sep 2011 22:36:06 +0200, "wolfgang kern" <>
    wrote:

    >
    >Muscipula mentoioned:
    >
    >>> The only way you can modify the IP - apart from a branch etc - is to
    >>> change the return address on the stack. This can be useful if you want
    >>> to read embedded data that is placed directly after the instruction to
    >>> the call. Fo example you can pass on a null
    >>> terminated string

    >
    >
    >> Yes, I write a assembler for the C-64 computer years ago and one of the
    >> built in things was a call to the "Print" function that would get the
    >> data following as text and simply return at the end of that text to move
    >> on to the next! Made the code look perty!

    >
    >|In fact I first used this method on my BBC Model B when I made osbyte
    >|and osword calls. Very handy.
    >
    >This text within code method may seem handy or funny on C-64 and
    >similar plain stupid code working CPUs.
    >
    >But it's extremely worse to mix code and data on a modern x86-CPUs.
    >(just read the friendly manuals about the matter)



    Non-writable data is fine in text segments, although you don't
    generally want to intersperse it between instructions inside a
    routine. But constants needed by a routine are usefully stored nearby
    (and x86-64 adds RIP relative addressing just for that).

    It's usually a terrible idea to store modifiable data anywhere near
    instructions on a modern processor - because most CPUs have distinct
    instruction and data caches, modifying a line cached in the i-cache
    usually leads to some extremely expensive cache invalidations.
    Robert Wessel, Sep 17, 2011
    #2
    1. Advertising

  3. On 9/16/2011 4:31 PM, Robert Wessel wrote:
    > On Fri, 16 Sep 2011 22:36:06 +0200, "wolfgang kern"<>
    > wrote:
    >
    >>
    >> Muscipula mentoioned:
    >>
    >>>> The only way you can modify the IP - apart from a branch etc - is to
    >>>> change the return address on the stack. This can be useful if you want
    >>>> to read embedded data that is placed directly after the instruction to
    >>>> the call. Fo example you can pass on a null
    >>>> terminated string

    >>
    >>
    >>> Yes, I write a assembler for the C-64 computer years ago and one of the
    >>> built in things was a call to the "Print" function that would get the
    >>> data following as text and simply return at the end of that text to move
    >>> on to the next! Made the code look perty!

    >>
    >> |In fact I first used this method on my BBC Model B when I made osbyte
    >> |and osword calls. Very handy.
    >>
    >> This text within code method may seem handy or funny on C-64 and
    >> similar plain stupid code working CPUs.
    >>
    >> But it's extremely worse to mix code and data on a modern x86-CPUs.
    >> (just read the friendly manuals about the matter)

    >
    >
    > Non-writable data is fine in text segments, although you don't
    > generally want to intersperse it between instructions inside a
    > routine. But constants needed by a routine are usefully stored nearby
    > (and x86-64 adds RIP relative addressing just for that).


    Yes, but, be careful: data in code segments, even read-only data in
    read-only code segments, is often useful in code hijacking.

    E.g. force a stack overflow, and instead of returning to a data page,
    which might, if you are very, very, lucky, have the NX (No Execute) bit
    set, instead return to the executable code page - but at the address of
    that read-only data item that happens to be equivalent to a piece of
    code that you (the user) don't want to have executed - but which the bad
    guy can take advantage of.

    It is for reasons like this that sole people consider RIP-relative code
    a gift to malware.

    Yes, RIP-relative makes it easier to relocate code for ASR (Address
    Space Randomization). But it also makes it easier to exploit certain
    holes, and to write attack code.
    Andy \Krazy\ Glew, Sep 17, 2011
    #3
  4. Re: An idea how to speed up computer programs and avoid waiting. ("event driven memory system")

    On Fri, 16 Sep 2011 17:54:14 -0700, "Andy \"Krazy\" Glew"
    <-arch.net> wrote:

    >On 9/16/2011 4:31 PM, Robert Wessel wrote:
    >> On Fri, 16 Sep 2011 22:36:06 +0200, "wolfgang kern"<>
    >> wrote:
    >>
    >>>
    >>> Muscipula mentoioned:
    >>>
    >>>>> The only way you can modify the IP - apart from a branch etc - is to
    >>>>> change the return address on the stack. This can be useful if you want
    >>>>> to read embedded data that is placed directly after the instruction to
    >>>>> the call. Fo example you can pass on a null
    >>>>> terminated string
    >>>
    >>>
    >>>> Yes, I write a assembler for the C-64 computer years ago and one of the
    >>>> built in things was a call to the "Print" function that would get the
    >>>> data following as text and simply return at the end of that text to move
    >>>> on to the next! Made the code look perty!
    >>>
    >>> |In fact I first used this method on my BBC Model B when I made osbyte
    >>> |and osword calls. Very handy.
    >>>
    >>> This text within code method may seem handy or funny on C-64 and
    >>> similar plain stupid code working CPUs.
    >>>
    >>> But it's extremely worse to mix code and data on a modern x86-CPUs.
    >>> (just read the friendly manuals about the matter)

    >>
    >>
    >> Non-writable data is fine in text segments, although you don't
    >> generally want to intersperse it between instructions inside a
    >> routine. But constants needed by a routine are usefully stored nearby
    >> (and x86-64 adds RIP relative addressing just for that).

    >
    >Yes, but, be careful: data in code segments, even read-only data in
    >read-only code segments, is often useful in code hijacking.
    >
    >E.g. force a stack overflow, and instead of returning to a data page,
    >which might, if you are very, very, lucky, have the NX (No Execute) bit
    >set, instead return to the executable code page - but at the address of
    >that read-only data item that happens to be equivalent to a piece of
    >code that you (the user) don't want to have executed - but which the bad
    >guy can take advantage of.



    I'll grant you that possibility, but instruction text has that problem
    as well. And is probably more likely to contain interesting sequence
    than typical literal/constant pools. Obviously having more stuff in
    executable pages increases the number of potentially useful sequences,
    but the instruction text is already chock full of various combinations
    of bytes - *and* long sequences of valid instructions.

    >It is for reasons like this that sole people consider RIP-relative code
    >a gift to malware.
    >
    >Yes, RIP-relative makes it easier to relocate code for ASR (Address
    >Space Randomization). But it also makes it easier to exploit certain
    >holes, and to write attack code.



    I'd expect RIP relative addressing to make code injection easier,
    though, as it makes it that much easier to create self-relocating
    code.
    Robert Wessel, Sep 17, 2011
    #4
  5. Re: An idea how to speed up computer programs and avoid waiting. ("event driven memory system")

    In alt.lang.asm [FUp set] Robert Wessel wrote in part:
    > Non-writable data is fine in text segments, although you don't
    > generally want to intersperse it between instructions inside a
    > routine. But constants needed by a routine are usefully stored
    > nearby (and x86-64 adds RIP relative addressing just for that).
    >
    > It's usually a terrible idea to store modifiable data anywhere near
    > instructions on a modern processor - because most CPUs have distinct
    > instruction and data caches, modifying a line cached in the i-cache
    > usually leads to some extremely expensive cache invalidations.



    Very good points. When performance matters, I try to keep
    even RO data away from I-cache read-ahead.

    This cache-thrashing might be a performance killer for interpreted
    languages (Java[script]) unless CPU designers hardwired a shortcut
    from D-cache to I-cache. When last I checked, they had not,
    and a 300 clock round-trip through main DRAM was necessary per
    cacheline. JIT could help if the lookahead was long enough to
    include whole loops. I wouldn't be surprised if emulation was
    faster than linewise interpreters.


    -- Robert
    Robert Redelmeier, Sep 17, 2011
    #5
    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.

Share This Page