Ticket #1174 (closed RFC: wontfix)

Opened 12 years ago

Last modified 11 years ago

Disallow .local declarations in long-style call statement

Reported by: kjs Owned by:
Priority: normal Milestone:
Component: none Version:
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:


the current implementation for PIR allows one to declare .locals in a .begin_call/.end_call sequence, after the .call directive, like so:

.begin_call .arg 1 .arg 2 .call $P0 .local int a, b, c .result a .result b .result c .end_call

(this is short for (a, b, c) = $P0(1, 2) )

IMHO, the whole sequence of directives from .begin_call to .end_call should be considered 1 statement; having .local declarations intermixed with .result directives is a bit strange, because the .local directive itself is not part of the sequence of directives to make the call.

Furthermore, the locals stay in scope after the .end_call directive.

I propose to disallow this language 'feature', and force the programmer to write the above example as follows:

.local int a, b, c .begin_call .arg 1 .arg 2 .call $P0 .result a .result b .result c .end_call

comments welcome.


Change History

Changed 12 years ago by coke

Changed 11 years ago by plobsing

  • status changed from new to closed
  • resolution set to wontfix

A PIR compiler isn't in the business of enforcing good style. The current PIR compiler copes fine with this sequence and there is no technical basis for dissallowing this syntax.

If this makes an alternate PIR compiler more complicated, it can be ommitted along with other misfeatures and bugs. I doubt anyone wants a bug-for-bug compatible remake of IMCC.

Note: See TracTickets for help on using tickets.