Instruction Set Evolution 
Author Message
 Instruction Set Evolution

Quote:

> Not yet mentioned...  Data boundry alignment stopped being
> required with S/370.  Only privileged instructions could get an
> 0C_    AHHHHGG!!!! Been so long since I got one, I forget what the
> program interrupt code is for boundry alignment...  ;-)

Been a wahile, but I had a STCK fail. I had written some assemberl code
to intercept all calls and returns in a PL/I application. I used it to
provide a homegrown performance analysis tool. I ever so politely
chained myself into the DSA chain. Problem was that the length of my DSA
was a multiple of 4 but not 8. So evey other save area in the DSA chain
was mis-aligned by 4 bytes. I would never have noticed except a PL/I
routine eventually called an assembler routine to get the TOD clock
value. oops.

Probably cause a lot of performance degradation with all those
misaligned double precision floating point numbers also.

--

Beyond Software, Inc.       http://www.*-*-*.com/
"Transforming Legacy Applications"



Fri, 26 Jan 2001 03:00:00 GMT  
 Instruction Set Evolution

Quote:

>> snip

>> I happen to like boundary checking, because aligned memory references
>> perform much better than unaligned. My two cents worth... ;-)

>I agree, but I may be old fashioned. Just how much does it matter
>anymore? On a 370 it was a big deal. What about teoday's processors
>(large and small).

It is hard to find much specific performance information about the /390.

Many modern processors do not allow misaligned data (SPARC, for one) and many
that do, do it much slower.  The Intel PentiumPro has this problem with
floating data, which is faster if doubleword aligned, but from the 486
days, it was only required to be word (32 bit) aligned, and many (many many)
only apply 32bit alignment to it.  While many things have changed over the
years, this one has not.

-- glen



Fri, 26 Jan 2001 03:00:00 GMT  
 Instruction Set Evolution

Quote:

>> One important case is TR, where the possible memory reference addresses
>> cannot be known in advance.
>No way. The possible addresses are in the range destination to destination + length
>(really length-1) and table to table plus 255. That covers a maximum of four pages.

It is not necessarily table to table+255, if the data to be translated does
not have that range.  If table is close to a page boundary, it is possible
that there is no reference to the page that table or table+255 are on.
It is not required that both pages exist if there is no reference to them.

At least as of S/370, TR won't page fault if the table entries needed by
the data to be translated exist.  They may have changed this by S/390, but
I would be surprised.

-- glen



Fri, 26 Jan 2001 03:00:00 GMT  
 Instruction Set Evolution

Quote:



>>> One important case is TR, where the possible memory reference addresses
>>> cannot be known in advance.
>>No way. The possible addresses are in the range destination to destination + length
>>(really length-1) and table to table plus 255. That covers a maximum of four pages.
>It is not necessarily table to table+255, if the data to be translated does
>not have that range.  If table is close to a page boundary, it is possible
>that there is no reference to the page that table or table+255 are on.
>It is not required that both pages exist if there is no reference to them.
>At least as of S/370, TR won't page fault if the table entries needed by
>the data to be translated exist.  They may have changed this by S/390, but
>I would be surprised.
>-- glen

I checked the S/390 POp to be sure.  As documented there, it will only do
the trial execution if operant 2 less than 256 bytes from a page boundary,
and DAT is on.  This is called "significant performance degredataion."

-- glen



Fri, 26 Jan 2001 03:00:00 GMT  
 Instruction Set Evolution
The /67 supported full 32-bit addressing so a 32-bit link register was a
necessity.  Hence BAS/BASR and several other changes to the architecture
definitions such as the return addresses for TRT, etc.

Bob

Quote:


> >In terms of when the Model 20 was first introduced, yes, I agree with Judy.
> >Underlying the concept, though, is that the entire link register was
> >devoted to the link address, whether 16 bit (as in the model 20) or 32 bit,
> >(as in the case of Extended Architecture), rather than the case with the
> >BAL, where 8 bits of the register were devoted to non address information.

> >Does anyone know if the 360/67 implemented BAS?  I very vaguely
> >recall that it did, but this memory is from examnination of Assembler G
> >op code tables, and it could be faulty.

> GX20-1703-9 lists BAS and BASR, for "Model 67".

> Andy Wood




Fri, 26 Jan 2001 03:00:00 GMT  
 Definitive S/370 Feature List (Re: ICM & STCM)

Quote:

>6 pages --
>  2 for the instruction
>  2 for the data area
>  2 for the translate table

If you want to be fussy, then you might need up to 8 pages -- 2 for
the EX instruction, 2 for the object TR instruction, 2 for the data
being translated and 2 for the translate table.

However, the earlier statement was about *data pages* required.



Sun, 28 Jan 2001 03:00:00 GMT  
 Definitive S/370 Feature List (Re: ICM & STCM)
First, let me say I don't mean to start a flame war.

I agree with the spirit behind the idea that alignment checking is
good because it can detect a clobber earlier in execution, before
memory is so corrupted that it's impossible to tell what happened.
But, really, error detection from alignment checking is very weak.

Why is support for debugging programs often so limited?

Why don't we have strong error checking in processors -- stack guards,
array boundaries, null (or "nil", if you prefer) pointer checking,
etc., all built in and with decent support from operating systems and
languages?

Another example: how long was it from the introduction of program
event recording on System/370 to decent application program support?
VM had it after a while, but for years MVS didn't support it, and then
the first support was only for the system itself (SLIP traps).

I still often work on systems where I cannot set a stop-on-store
breakpoint at all.

Most annoying to me is that there's no indication of any hope of
improvement in this situation on the horizon.  Just more crashes from
Windows 98, 00, -9998, ...  (that's a very lame Y2K joke).



Sun, 28 Jan 2001 03:00:00 GMT  
 Definitive S/370 Feature List (Re: ICM & STCM)

Quote:


>>6 pages --
>>  2 for the instruction
>>  2 for the data area
>>  2 for the translate table
>If you want to be fussy, then you might need up to 8 pages -- 2 for
>the EX instruction, 2 for the object TR instruction, 2 for the data
>being translated and 2 for the translate table.

This is another question.  When is the page fault when an instruction
crosses a page boundary?

Quote:
>However, the earlier statement was about *data pages* required.

OK, again.  This is the maximum pages required.  The question is, which
pages are required?  If the second argument (translation table) crosses
a page boundary, it is possible that one page or the other is not
required.  The machine will not page fault for that page.  It is required
not to.  The requirement exists because the page might not exist.

The fun of adding virtual addressing onto an existing architecture, and
making sure that it is upward compatible.

-- glen



Mon, 29 Jan 2001 03:00:00 GMT  
 Definitive S/370 Feature List (Re: ICM & STCM)
. . . . .

Quote:
> This is another question.  When is the page fault when an instruction
> crosses a page boundary?

During instruction fetch, isn't it?

. . . .

Quote:
> OK, again.  This is the maximum pages required.  The question is, which
> pages are required?  If the second argument (translation table) crosses
> a page boundary, it is possible that one page or the other is not
> required.

Sure. I'm no expert on s/370 microprograms, but as the TR instruction
is defined in the architecture to access the translate table one byte
at a time by indexing the translate table address with the source byte
value I can hardly imagine any fetch to other bytes than those actually
referred to in the table.

And as quoted from PoP: "Access exceptions are recognized only for
those bytes in the second operand which are actually required."

regards Sven
. . . . .



Mon, 29 Jan 2001 03:00:00 GMT  
 
 [ 109 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software