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

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

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.

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.

On Fri, 16 Sep 2011 17:54:14 -0700, "Andy \"Krazy\" Glew"
<> 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.

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