Re: Pointer arithmetic error

[David Given <dg@cowlark.com>]

[-- Attachment #1: Type: text/plain, Size: 3431 bytes --]

Tommy Thorn wrote:
[...]
> Yes, but it would have been better to have kept all the white space
> changes for a separate change so we could just see that relevant changes.

Corrected; turned out it had been so long since I've used a diff that
didn't use my alias I'd forgotten you have to explicitly tell it to
ignore white space.

> This introduces divides all over the place for all users, replacing a
> very cheap constant shift with an expensive divide. All sparse users
> would be paying the cost for a feature that is useful for 1 user, I
> think we should perhaps think carefully about this.

I really don't think this is an issue. Certainly, a division by a
variable is more expensive than a shift by a constant... but you'd have
to do billions of them before anyone actually started to notice. If it
really did turn out to be an issue, it would be simple enough to change
later to "value >> bits_in_char_power_of_2".

> One obvious solution would be to introduce a BITS_IN_CHAR macro in
> target.h defaulting to 8 and let "exotic" architectures redefine it to
> bits_in_char. This is very similar to the approach GCC is using.

The problem with this approach is that it involves recompiling all of
sparse for each target, which is a bit user unfriendly. Currently all
configuration can be done at run time, which allows such nice features
as having all potential back-ends share the same code via shared libraries.

> On a completely unrelated node, I'm excited to see your work on using
> sparse for compilation. Hopefully your experience will lead to it being
> easier for the next guy. I would like to see sparse target for a simple
> abstract machine, but I so far haven't had time to work on it.

sparse is working rather well, and seems to be one of the better
compiler front ends that I've found. The linearising support is
particularly helpful. I have, however, been finding that the learning
curve is rather steep --- the API shows a lot of signs of having grown
organically over time --- and I've had to build big chunks of code that
I'm sure are unnecessary. For example, in order to generate the right
kind of code, I need to figure out whether a pseudo contains an integer,
float or pointer. The only way I've found out to do this is to
recursively follow the chain of pseudo->def pointers until I find an
instruction with enough type information attached to it to figure it
out. I'm sure there must be an easier way of doing this...

(BTW, given a function symbol, how do I find its return type? I can find
the list of arguments, but there's nothing in struct symbol that seems
to refer to the return value...)

I am intending to release my project once done, of course, and I hope
people will find it useful, but I'm not sure how much general use it
will be; I've basically ripped out and replaced the register allocator /
storage mechanism from my back end as I didn't understand it and didn't
need the complexity. That should probably all get rewritten properly at
some stage, but right now I'm focusing on getting things working...

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]