[Simh] O2 optimization on Linux (was: VMS 4.6 crashes on Linux)
Peter Allan
petermallan at googlemail.com
Sun Jan 2 09:13:07 EST 2011
Timothe,
I just tried your suggestion, but it does not help. I have got the assembler
outputs on the two systems. It is of course very long, so I am putting what
I reckon to be the relevant parts here. I can send you the full listings if
you need them.
I say these are the relevant parts based on:
The 780 emulator works if I comment out the line
ML_PXBR_TEST (t + 0x800000);
from vax_cpu1.c
It also works if I change the line
ML_PXBR_TEST (t + 0x800000);
to
t2 = t + 0x800000;
ML_PXBR_TEST (t2);
having defined t2 to be int32, since t is defined to be int32.
It looks like the macro is not handling the addition of 0x800000 correctly.
There is another part of the code where this is done. I did not need to
change that to get the emulator to work, but perhaps what I am doing does
not exercise that part of the code.
--- C code extracted from vax_cpu1.c
ASTLVL = t; /* restore AST */
t = ReadLP (pcbpa + 88);
ML_PXBR_TEST (t + 0x800000); /* validate P1BR */
--- Extract from vax_cpu1.s compiled on Fedora Core 14 -- This is what
works
.L318:
movl -32(%rbp), %eax
movl %eax, ASTLVL(%rip)
movl -20(%rbp), %eax
addl $88, %eax
movl %eax, %edi
call ReadLP
movl %eax, -32(%rbp)
movl -32(%rbp), %eax
addl $8388608, %eax
testl %eax, %eax
jns .L319
movl -32(%rbp), %eax
addl $8388608, %eax
andl $3, %eax
testl %eax, %eax
je .L320
.L319:
movl $-24, %esi
movl $save_env, %edi
call longjmp
.L320:
movl -32(%rbp), %eax
--- Extract from vax_cpu1.s compiled on CentOS 5.5 -- This is what fails
.L540:
movl -4(%rbp), %eax
movl %eax, ASTLVL(%rip)
movl -8(%rbp), %eax
addl $88, %eax
movl %eax, %edi
call ReadLP
movl %eax, -4(%rbp)
cmpl $-8388608, -4(%rbp)
jge .L542
movl -4(%rbp), %eax
addl $8388608, %eax
andl $3, %eax
testl %eax, %eax
je .L544
.L542:
movl $-24, %esi
movl $save_env, %edi
call longjmp
.L544:
movl -4(%rbp), %eax
----------
My assembler is a bit rusty, but there are clear differences between the
two.
Peter Allan
On 31 December 2010 18:07, Timothe Litt <litt at ieee.org> wrote:
> This test appears to be implementing the constraint that p0/1 base
> register values must be in in system space (bit 31 set) & longword aligned
> (bits 0,1 clear).
>
> I don't think it's parens; there seem to be enough.
>
> If this is a 64-bit environment, you might be seeing a sign extension /
> unsigned promotion issue in the complier.
>
> You might try this to make what's desired explicit:
>
> #define ML_PXBR_TEST(r) if (((((uint32)(r))& 0x80000000u) == 0) || \
>
> ((r)& 0x00000003)) RSVD_OPND_FAULT
>
> But it would really help to see the assembler generated for the two cases -
> especially the one that fails.
>
> ---------------------------------------------------------
> This communication may not represent my employer's views,
> if any, on the matters discussed.
>
>
>
> ------------------------------
> *From:* simh-bounces at trailing-edge.com [mailto:
> simh-bounces at trailing-edge.com] *On Behalf Of *Peter Allan
> *Sent:* Friday, December 31, 2010 12:32
> *To:* simh at trailing-edge.com
> *Subject:* Re: [Simh] O2 optimization on Linux (was: VMS 4.6 crashes on
> Linux)
>
>
>
> On 28 December 2010 22:00, Bob Supnik <bob at supnik.org> wrote:
>
>> Jason Stevens wrote:
>>
>> You didn't build it with -O2 on linux did you? There is some weird
>> things with GCC and SIMH's VAX... I can only speak to 4.X BSD, but I
>> was able to identify two procedures that when optimized with -O2 break
>> 4BSD on SIMH....
>>
>> I kind of detailed it here:
>>
>> http://www.mail-archive.com/simh@trailing-edge.com/msg00463.html
>>
>> And the procedures in question were:
>>
>> op_ldpctx
>> op_mtpr
>>
>> ---
>>
>> Interestingly, those routines are the ONLY places in the VAX simulator
>> where these macros are used:
>>
>> /* Machine specific reserved operand tests (all NOPs) */
>>
>> #define ML_PA_TEST(r)
>> #define ML_LR_TEST(r)
>> #define ML_SBR_TEST(r)
>> #define ML_PXBR_TEST(r)
>> #define LP_AST_TEST(r)
>> #define LP_MBZ84_TEST(r)
>> #define LP_MBZ92_TEST(r)
>>
>> On the 780, they are real tests:
>>
>> /* Machine specific reserved operand tests */
>>
>> #define ML_LR_TEST(r) if ((uint32)((r)& 0xFFFFFF)> 0x200000)
>> RSVD_OPND_FAULT
>> #define ML_PXBR_TEST(r) if ((((r)& 0x80000000) == 0) || \
>> ((r)& 0x00000003)) RSVD_OPND_FAULT
>> #define ML_SBR_TEST(r) if ((r)& 0x00000003) RSVD_OPND_FAULT
>> #define ML_PA_TEST(r) if ((r)& 0x00000003) RSVD_OPND_FAULT
>> #define LP_AST_TEST(r) if ((r)> AST_MAX) RSVD_OPND_FAULT
>> #define LP_MBZ84_TEST(r) if ((r)& 0xF8C00000) RSVD_OPND_FAULT
>> #define LP_MBZ92_TEST(r) if ((r)& 0x7FC00000) RSVD_OPND_FAULT
>>
>> ---
>>
>> One (or more) of those six tests is the smoking gun, and if I had to put
>> my money on it, I think it's this one:
>>
>> #define ML_LR_TEST(r) if ((uint32)((r)& 0xFFFFFF)> 0x200000)
>> RSVD_OPND_FAULT
>>
>> Try adding an extra level of parentheses:
>>
>> if (((uint32)((r)& 0xFFFFFF))> 0x200000) RSVD_OPND_FAULT
>>
>>
>> just to be sure that the uint32 cast isn't be applied to the whole
>> comparison, instead of just the first term.
>>
>> If that fails to get it running, then try "no-oping" all of the macros to
>> see if VMS 4.6 will boot. If it does, then enable each of the macros in
>> turn, to see where the simulator fails.
>>
>> /Bob
>>
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>
> Bob,
>
> I tried removing the macro definitions one by one. The one that causes the
> problem is ML_PXBR_TEST, i.e. if this is defined as nothing and the rest are
> left as per vax780_defs.h, then the 780 emulator works on CentOS 5.5. This
> is the macro with two comparisons in it. I wonder if that is significant?
>
> I tried putting in some extra parentheses, but this did not help.
>
> Of course, it all still works on Fedora Core 14. I will see if I can
> compare the assembler that is generated for vax_cpu1.c on the two systems.
>
> Peter Allan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20110102/1ad9085c/attachment-0002.html>
More information about the Simh
mailing list