>> goto! Yikes! This needs to go! It makes the flow of this function hard to
>> follow, and I'm sure it's not doing the compiler any favors.
For the record, I think this knee-jerk reaction to goto is completely
misguided. Goto is frequently wrong, but when it is used as an escape
function (e.g. like break), I believe that it is totally justified.
Any time you try to avoid a goto in these situations, you increase the
level of nesting by writing an if-statment. My belief is that goto is
ideal for escaping more than one level of looping (some languages have
explicit support for this), or to execute error handling code before
returning from a function.
> Actually I don't think it's hard to follow at all. Normally we pick the
> next available address if the user doesn't provide one, and in the
> somewhat exceptional case that the user provided an address *but*
> part of the range is already in use *and* the MAP_FIXED flag wasn't
> specified to force an override of that prior use, then you also fall
> back on that policy. Obviously the goto isn't strictly necessary,
> but IMO rewriting to avoid the goto does not make the logic more
> apparent or easier to follow (if anything, the opposite).
I actually don't think it's that hard to follow, but I agree that it's
strange. I think a common way to write this would be to use a flag
variable that's false to start, gets set to true in the one place, and
then replace the } else { chunk of code with an if (flag) {
> You are right that goto can have a negative impact on compiler optimization,
> but if you're spending a measurable fraction of your runtime calling mmap()
> then you have bigger problems than suboptimal simulation speed.
That depends. If you use goto to replace normal looping stuff, yes,
but if in the end, you need to replace the goto with a bunch of extra
if-statements, it may not matter.
Nate
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
