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:
signature.asc
Description: OpenPGP digital signature
