On Sep 29, 2008, at 1:29 PM, Scott Graham wrote:> On Mon, Sep 29, 2008 at 12:41 AM, OvermindDL1 > <overminddl1 at gmail.com> wrote: >> I have ended up making a rather complicated type system to handle >> quite a few things, all stemming from the fact that the integer type >> has no sign information (even if it did not use it, would be nice to >> look at it in my code generator to so I can put out one function type >> [snip] > > It's a bit unfortunate, but as far as I understand, you have to just > deal with having two type systems in the front end.Yes, the answer is to have your own type system in your front-end. We designed the LLVM IR to be optimizable, not to let you avoid defining a type system :) -Chris
I know why it was removed, and it does make sense, just would be nice if there was an option to be able to get two pointer to a specific llvm::IntegerType, functionally they would be identical, but for user code (hence, my code) would be useful as I could match it for the different ones at generate different code for each. With some discussion with others I think we came up with an acceptable method (which allows me to completely kill my type duplication system, thank god). I am going to go down the area of Java/Python/Lua/whatever_else and just have normal operators (/, shifts, etc...) act as if the integers are signed. But there will also be named ops (udiv/sdiv) which can be used in place of a symbol op (such as /) to be explicit for those who really need unsigned usage. I plan for the operators to actually all be named (so instead of + someone could put add instead for example), and am just allowing the symbol ones to allow it to be easier to pick up for non-such-low-level-programmers. I think it is a decent enough compromise (and it was not entirely my idea, I like the back-end ugly coding, not front-end pretty syntax :) ). The main issue I was having with my type system was not that is was hard (I think it is actually well designed and powerful), it just caused me to have to write 'wrappers' around near everything in llvm, from functions and blocks to expressions and all, it literally just started snowballing, and since I am programming by myself, I need something a little more efficient in this case... Either way, what do you think of the above style for handling integers now, think it will work? See any major issues with it? You think people would have trouble using that style?
OvermindDL1 wrote:> > I know why it was removed, and it does make sense, just would be nice > if there was an option to be able to get two pointer to a specific > llvm::IntegerType, functionally they would be identical, but for user > code (hence, my code) would be useful as I could match it for the > different ones at generate different code for each. >Well a language doesn't need to know whether an int is signed or unsigned if all the operators are aware of the sign of its operands. Such is the case with most assembly languages, and now LLVM. It makes the assembly cleaner (because types are used only for checking, not for overloading operations). And it seems you're going this way with your language (based on what you said in the most recent post). The thing is that high level languages really should encode signed/unsigned into the type system (or simply deal only with signed integers, as many languages do). You don't want your human programmers having to worry about the signedness of an int each time they do anything with it. OvermindDL1 wrote:> > With some discussion with others I think we came up with an acceptable > method (which allows me to completely kill my type duplication system, > thank god). > *snip* > Either way, what do you think of the above style for handling integers > now, think it will work? See any major issues with it? You think > people would have trouble using that style? >Well it will certainly work, but it's a pretty low-level / unsafe feature to have in any language higher than assembly language. I wouldn't like it if I was a user. But at least if I want to I can pretend there aren't any unsigned ints and go about my merry way (so that's OK, the only problem is when I actually want to use an unsigned int). The thing is, practically any language higher than assembly is going to require a type system, and that type system is almost certainly going to be different to LLVM's. (eg. How do you distinguish dynamic arrays from pointers? How do you give names to structure types? How do you distinguish characters from i8s? Strings from arrays of i8s?) LLVM can't possibly provide a rich enough type system for all the front-end languages; its type system isn't designed to be used that way. The cleanest compiler design (in my opinion) will have a completely type-checked program before it touches the LLVM API at all. The compiler should then always generate type-correct LLVM code (so your users should never see LLVM type errors, if your compiler is behaving correctly). -- View this message in context: http://www.nabble.com/Integer-handling-tp19719560p19735288.html Sent from the LLVM - Dev mailing list archive at Nabble.com.