[m-dev.] MSVC and --no-smart-indexing

[Paul Bone]

On Mon, Feb 09, 2015 at 12:32:24PM +1100, Zoltan Somogyi wrote:
> On Mon, 9 Feb 2015 10:32:12 +1100, Paul Bone <paul at bone.id.au> wrote:
> > > I don't have any convenient way to test cross-compilation between
> > > 32 and 64 bit systems, but if someone does, I could generate diffs
> > > for them to test.
> > 
> > I can test this.
> 
> OK. I will look at the smart indexing code for both backends with an eye
> for cross compilation.
>  
> > > This should be fixable by having the hash functions mask out bits
> > > above e.g. 2^30 on all platforms.
> > 
> > That's easy enough to do and except for the most extreme cases it won't
> > cause any significant issues.
> 
> Implemented by the attached diff, for review by anyone.

I'll try to look at it soon.  Thanks

> > However it will only work well if there are some string primates that will
> > return the Nth character without testing the length of the string on every
> > call, that return the "rest" of the string without copying it (we might have
> > this already),
> 
> No, that operation does not exist, and it CANNOT exist. If S1 points to
> a string, and you applied this operation to assign to S2 (say) all the
> chars in S1 after the 10th, and S1 became dead, then Boehm would
> collect the block containing the string, and then S2 would become
> a dangling pointer.
> 
> We could have a restricted version that would work only for values on N
> that we have registered as allowed offsets with Boehm, which would mean
> 1-7 for 64 bit platforms. That may be useful enough for tries, but would
> complicate the implementation, since trie nodes on different sides of depth 7
> would need different handling.

Ah, I forgot that there was a limit to Boehm's support for interior
pointers.

> > and that will return the null byte at the end of the string
> > and allow our switch code to test to see if the byte is null.  Also this
> > won't support unicode without some extra effort.
> 
> It should be possible to mostly ignore Unicode by working on code units,
> not code points.
> 
> > It may have already been fixed in more recent versions of MSVC.  I don't
> > have access to these so I don't know.  If not then I would guess that they
> > would laugh at us for being so small but claiming that our compiler is more
> > robust.
> 
> I am not claiming that in general, just in this specific instance.
>
> > That said, our compiler is probably exercised less than there's.
> > Apart from G12 (or whatever it is these days) and PrinceXML I don't think
> > Mercury has to deal with machine generated code very often.
> 
> But at least we TRY to deal with it.

Yes, I think it's an attitude thing.


-- 
Paul Bone