[Mono-devel-list] Re: Abcremoval

Willibald Krenn Willibald.Krenn at gmx.at
Tue Feb 1 08:36:00 EST 2005


Massimiliano Mantione schrieb:
> I cc the list because this could be of general interest, hope
> you don't mind...

Nope, not at all..

>>	public int Read() {
>>		return pos < xml.Length ? (int) xml [pos++] : -1;
>>	}
[excellent explanation skipped]

Let's see, if I understood you correctly; Following steps would be 
necessary to support some simplified version of string access bounds 
check removal:
  -> Simplify example by making 'pos' unsigned int and possibly 
introducing an overload Char indexer. (Or do some other trick so abcrem 
can be sure that the index will never be treated as signed.)
  -> Turn on abcrem on methods with calls to this method (Could be some 
separate flag like MONO_CFG_HAS_UNSIGNEDCHARINDEXER
  -> Add the capability to abcrem to scan for strlen/getchar opcodes if 
above flag is set. If BBs are found to be dominated by condition
var < strlen, scan for unsigned char getter calls and operations on the 
var; If it's safe, mark the bounds check as obsolete.

BTW: Currently the string index is multiplied by two (shl) before 
accessing the char in the string. This means that the index can not be 
in range <0 or >0x7fffffff. (As the MSB will be shifted away.) I don't 
know if this a bug or a feature, but effectively this means that even 
today all accesses to string chars are '31-bits unsigned'. This means 
that any 'bge' with System.String::get_Length() on stack can be turned 
into an unsigned compare.. If this would be done, then abcremoval could 
even assume signed integers to always be > 0..
I have to confess though, that this would be some dirty trick.

> If you really want to work on it, read the doc file I wrote (it
> is in 'docs/abc-removal.txt'), and the paper I reference there.
> 
> Then, ask for specific doubts ;-)

I guess I'll better concentrate on my cont. optim. framework for now. 
But I already read through your docs/abc-removal text.. :-)

Thanks,
   Willi




More information about the Mono-devel-list mailing list