One of my pet peeves is when IPCS (for example) does this:
40404040 40404040 40404040 ||
0010 ||
0020 Next X'0010' bytes same as above
0030 40404040 40404040 40404040 ||
Why not just
Keven
I agree - I would *love* to know how to override this behaviour in IPCS - I
find that it gets in the way much more than it helps.
Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com
On 10/7/2010 12:06 PM, Rob Scott wrote:
I agree - I would *love* to know how to override this behaviour in IPCS - I
find that it gets in the way much more than it helps.
It would be nice if the person analyzing the dump could tell IPCS that it would
take at least 256 equal bytes (for
On 10/7/2010 1:06 PM, Rob Scott wrote:
I agree - I would *love* to know how to override this behaviour in IPCS - I
find that it gets in the way much more than it helps.
Sometimes. I remember once entering a thoughtlessly composed operator
command,
perhaps d u, whatever and watching
My first post was remiss in not noting another important use of
blanks-substring detection, which is due originally to the late John Cocke.
The most important determinant of the performance of a translator--compiler,
interpreter, assembler, whatever--is the speed and efficiency with which it
At 02:51 + on 10/08/2010, john gilmore wrote about Re: 16 bytes the same:
Apart from its obvious usefulness in processing right-to-left text
like that of Arabic, Farsi, and Hebrew, the TRTR instruction is
valuable for locating the rightmost non-blank character in
left-to-right text.