🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c++
Article #2708

Re: an optimization I claim is illegal

#2708
From: Fergus Henderson
Date: Fri, 24 Nov 1995 12:16
63 lines
3711 bytes
chase@centerline.com (David Chase) writes:

>[...] I think it is a mistake to argue the point in terms
>of 486 assembly language.

Although I don't agree with John Skaller's conclusion,
I do think he is using a legitimate line of argument.
x86 CPUs are pretty common; if the C++ standard makes certain
optimizations impossible on those CPUs and others like them,
and this has a significant impact on the performance of C++ code,
then this would be a bad thing, and it would be reasonable
to suggest that perhaps the C++ standard should be changed.

As it turns out, I don't think the C++ standard prevents the
optimization that Skaller was talking about (caching the value of the
`this' pointer in a segment/offset register pair over a member function
call).

>Furthermore, the situation described
>
>> This machine code may LOOK OK, but it ISNT. Why? Because an
>> interrupt may come flying in after the call to f and before the
>> return. The machine registers are pushed onto the stack
>> in the interrupt. After the interrupt has done its job
>> it pops the register back. WOOPS!!! A segment register
>> gets loaded with an invalid address. A general protection
>> fault ensues.
>
>sounds odd to me -- to me, this sounds like quality of OS
>implementation, not standards stuff (why would an interrupt handler
>fail to put the registers back?  Is this some DOS thing?).

I think you may possibly have missed Skaller's point here - the problem
is not that the interrupt handler doesn't try to restore the original
register contents.  The problem is that when it does attempt to do so,
it gets a GPF, because the segment registers contained values which
have since become invalid (because the segment that they point to has
since been deallocated), and so merely pushing them and popping them
can cause a GPF.

However, I agree that a better OS and/or C++ implementation could avoid
the problem.  For example, interrupt routines could set a flag before
restoring segment registers; if a GPF happened while this flag was set,
the GPF handler could just set the segment register to zero and then
continue.

The existence of this technique implies that the C++ standard does not
prevent caching the value of the `this' pointer in a segment/offset
register pair over a member function call.  It is conceivable that this
optimization might not be possible with certain (low-quality) operating
systems, but the problem would not unique be to C++ - such OSs would
also in general prevent caching *any* pointer in a segment/offset
register pair over *any* function call.  As a result, I don't think
Skaller's argument holds up.  I think the C++ standard is right to
allow code such as `delete this;'.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
Technical Details
Message-ID: <9532822.27043@mulga.cs.mu.OZ.AU>
Path: arc1-ca.pugleaf.net!in2.uu.net!bounce-back
References: <48ngom$r5f@oznet07.ozemail.com.au> <48r0b9$d07@wcap.centerline.com>

Show Full Headers
Complete Article Headers
Approved: fjh@cs.mu.oz.au
Date: 24 Nov 95 12:16:38 GMT
From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
Message-ID: <9532822.27043@mulga.cs.mu.OZ.AU>
Newsgroups: comp.std.c++
Organization: Computer Science, University of Melbourne, Australia
Path: arc1-ca.pugleaf.net!in2.uu.net!bounce-back
References: <48ngom$r5f@oznet07.ozemail.com.au> <48r0b9$d07@wcap.centerline.com>
Subject: Re: an optimization I claim is illegal
X-Original-Date: Fri, 24 Nov 1995 11:11:42 GMT
X-Auth: PGPMoose V1.1 PGP comp.std.c++
 iQBFAgUBMLW3vuEDnX0m9pzZAQG7aAF/Yzw/qiaPE3Q3JipeItvNAyCXMkR6DN3e
 +hHrvKhIAuIh58OYSB8NEjCh6bMJnrO/
 =Y9Ai