Re: [Mesa3d-dev] Tool to process .syn files?
On Friday 18 May 2007 01:53:53 pm Ian Romanick wrote: Yeah, that's where Roberto came in :) We used QLALR which is simply amazing and for those who ever used Bison a lot more convenient than what we had right now. http://labs.trolltech.com/page/Projects/Compilers/QLALR Initially we used QLALR with Flex, then we just went only with QLALR (Flex is really bad when its come to its usage in libraries and there was no real reason for it). If you ever used yacc then you can use qlalr right away. QLALR generated files are simply so much better it was just worth it. I think Roberto could write a book about why QLALR just rocks and it makes sense to use it in this case (granted that the book would have limited audience and I'll let him do that once his back) rather than anything else. For those of us (e.g., me) not deep in Qt...how the heck do you build qlalr?!? You'll need libQtCore4 and qmake. If you already have them run qmake make, you'll get qlalr binary and you're done. (also avoid excessive usage of punctuation marks, Qt is mostly unaffected by them, but it makes me flutter my eyelashes in a very neat way) Also, does it only generate C++? Yes. At least at the moment. Zack - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Tool to process .syn files?
Zack Rusin wrote: On Friday 18 May 2007 05:07:08 am Keith Whitwell wrote: Sounds good. I've been thinking about LLVM and Mesa a little bit the last few days. If it can be made to work, it seems like a good way to go. There are a couple of practical issues that should be taken into account though: - Firstly, we need to continue supporting the existing drivers. In particular this means we need to generate programs they can understand (ie in the current Mesa IR), up until the point at which they all understand LLVM. Hmm, that's a good point. To be honest I haven't really thought about that. - Secondly, I'm not yet convinced that LLVM in its current state really can support the wierdnesses of native GPU architectures. There are some assumptions that seem to be encoded in LLVM that don't apply on GPU's -- things like the availability of a general branch instruction, for instance. Yeah, I've been stressing over this a little bit as well. It's not so much LLVM IR that stresses me as their optimization passes. LLVM IR is pretty extensible and I thought about simply extending it with if/else constructs - my main conceptual problem is that I was afraid that potentially arbitrary optimization passes could destroy that structure. Currently what I wanted to do is handle it in a separate lowering pass. Meaning that if the hardware doesn't handle branching the lowering pass tries to decompose it to some form of if/else constructs (which is really not lowering but highering =) but you get the point). Conceptually it's not rocket science but a question of whether this will work and work well is a whole different issue and hard to answer. On this second level as well, I feel a lot more comfortable with the idea of an intermediate step in this project where the LLVM optimizer targets something like the Mesa IR (or the cleaned up version we have been working on internally) as its initial output, and then look at hardware in a second phase. The problem with this is that the optimization passes operate on LLVM IR, and they're transforming passes so technically even though your input maybe didn't have any branches the output might very well have them. So a highering pass would need to be run either before or during compilation to Mesa IR. And if we have that pass then translation to Mesa IR doesn't make so much sense as we can have LLVM IR with our intrinsics that the code generators in drivers understand. 1) The Mesa IR has many of the characteristics of the hardware ISA's, with supposedly high level GPU/SIMD constructs like IF/THEN/ELSE opcodes as opposed to CPU-world ideas like labels branches. Generating this would be a good validation of LLVM for this work. Like I mentioned above that can done by just extending LLVM. It's not really clean but I'm sure we could kung-fu kick LLVM guys to do it properly for us. 2) The i965 is an intricate device to program, especially without docs or a simulator/debugger. The register horizontal/vertical stride and step addressing modes are pretty unique (and confusing), for instance. Going all the way to hardware seems like a big task to do in a single development step. The IR-hardware translation will have to happen at some stage anyway. With LLVM passes hardware can at least easily decide what kind of IR it would be most comfortable with so I don't think it would be much harder than with dedicated IR for the given hardware. 3) As noted above, we need to get to the mesa IR somehow for other devices. That's a good point. But if we're talking about the IR infrastructure that the drivers use right now then that's not a problem. I think that in this case just a general code-generator would suffice. OK. What I would suggest is to make this the first goal, ie code-generate the Mesa IR, then use the lessons from that to feed into follow-on work to code-generate i965 programs. Not that I'm saying to stop what you're doing - carry on as you like, but this is probably the way I'm going to investigate things. Keith - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Tool to process .syn files?
Zack Rusin wrote: On Friday 18 May 2007 05:07:08 am Keith Whitwell wrote: Sounds good. I've been thinking about LLVM and Mesa a little bit the last few days. If it can be made to work, it seems like a good way to go. There are a couple of practical issues that should be taken into account though: - Firstly, we need to continue supporting the existing drivers. In particular this means we need to generate programs they can understand (ie in the current Mesa IR), up until the point at which they all understand LLVM. Hmm, that's a good point. To be honest I haven't really thought about that. - Secondly, I'm not yet convinced that LLVM in its current state really can support the wierdnesses of native GPU architectures. There are some assumptions that seem to be encoded in LLVM that don't apply on GPU's -- things like the availability of a general branch instruction, for instance. Yeah, I've been stressing over this a little bit as well. It's not so much LLVM IR that stresses me as their optimization passes. LLVM IR is pretty extensible and I thought about simply extending it with if/else constructs - my main conceptual problem is that I was afraid that potentially arbitrary optimization passes could destroy that structure. It looks like conditional branches in the LLVM IR are somewhat structured. From http://llvm.org/docs/LangRef.html#terminators Test: %cond = icmp eq, i32 %a, %b br i1 %cond, label %IfEqual, label %IfUnequal IfEqual: ret i32 1 IfUnequal: ret i32 0 It might not be too hard to generate IF/ELSE/ENDIF GPU instructions from that. But if the optimizer changed the structure... hmmm. I was looking at LLVM's vector support a little more. There's basic vector add, sub, mul, divide and shuffling, but that's about it. GPU instruction sets have vector min/max, abs, lrp, dot product, frac and set-if-less/greater/equal, etc that are commonly used in shader code. I think it's important that the code generator emits those instructions, rather than scalar decompositions. It seems that either the LLVM IR would need some extensions for those things or the back-end code generator/instruction selector would have to look for patterns of scalar instructions and figure out where vector ops should be used. The later sounds unpleasant. -Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Tool to process .syn files?
Brian Paul wrote: Zack Rusin wrote: On Friday 18 May 2007 05:07:08 am Keith Whitwell wrote: Sounds good. I've been thinking about LLVM and Mesa a little bit the last few days. If it can be made to work, it seems like a good way to go. There are a couple of practical issues that should be taken into account though: - Firstly, we need to continue supporting the existing drivers. In particular this means we need to generate programs they can understand (ie in the current Mesa IR), up until the point at which they all understand LLVM. Hmm, that's a good point. To be honest I haven't really thought about that. - Secondly, I'm not yet convinced that LLVM in its current state really can support the wierdnesses of native GPU architectures. There are some assumptions that seem to be encoded in LLVM that don't apply on GPU's -- things like the availability of a general branch instruction, for instance. Yeah, I've been stressing over this a little bit as well. It's not so much LLVM IR that stresses me as their optimization passes. LLVM IR is pretty extensible and I thought about simply extending it with if/else constructs - my main conceptual problem is that I was afraid that potentially arbitrary optimization passes could destroy that structure. It looks like conditional branches in the LLVM IR are somewhat structured. From http://llvm.org/docs/LangRef.html#terminators Test: %cond = icmp eq, i32 %a, %b br i1 %cond, label %IfEqual, label %IfUnequal IfEqual: ret i32 1 IfUnequal: ret i32 0 It might not be too hard to generate IF/ELSE/ENDIF GPU instructions from that. But if the optimizer changed the structure... hmmm. I was looking at LLVM's vector support a little more. There's basic vector add, sub, mul, divide and shuffling, but that's about it. GPU instruction sets have vector min/max, abs, lrp, dot product, frac and set-if-less/greater/equal, etc that are commonly used in shader code. I think it's important that the code generator emits those instructions, rather than scalar decompositions. It seems that either the LLVM IR would need some extensions for those things or the back-end code generator/instruction selector would have to look for patterns of scalar instructions and figure out where vector ops should be used. The later sounds unpleasant. Yes, approximately 50% of the time, we need to preserve the vector semantics. The other 50% of the time, we need to convert vector operations to scalar ones. In the i965, for instance, vertex programs execute with vector semantics (8-wide registers hold xyzw for two vertices) and fragment programs execute with scalar semantics (16-wide register pairs hold x for 16 pixels -- this is one way to run out of registers quickly). Currently the vector-scalar transition is handled by the driver, it would be interesting to do this at a higher level, but we need to preserve the ability to extract .xyzw-style vector instructions. I've had limited time to look into this, unfortunately. I'm concentrating first on getting the code I've got into some reasonable form to commit. Keith - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Tool to process .syn files?
On Monday 21 May 2007 03:11:28 pm Keith Whitwell wrote: It seems that either the LLVM IR would need some extensions for those things or the back-end code generator/instruction selector would have to look for patterns of scalar instructions and figure out where vector ops should be used. The later sounds unpleasant. Yes, approximately 50% of the time, we need to preserve the vector semantics. The other 50% of the time, we need to convert vector operations to scalar ones. Right :) That's exactly what we'll need the lowering pass for (the one that I wanted to commit last week ;) ). Basically the way I envisioned it is that we'd have a general module wide lowering pass (LLVM has a real nice framework for running passes over the module) that can be controlled by the driver. So the driver marks the things that need to be lowered (decomposed) for it, everything else basically stays as a builtin. That of course works really nicely in the hardware case and is a little more problematic in the software-only case (because the default llvm code-generator won't understand those not-lowered builtins). So for all the things we'll be missing and can be done reasonably with vectors all the way we'll add llvm intrinsics (which is pretty trivial to do and gives us the flexibility we'll need). And most likely we should push for some of them to be folded back in llvm but that's something for the future. Zack - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Tool to process .syn files?
On Thursday 17 May 2007 05:36:45 pm Keith Whitwell wrote: I think the Zack/Roberto LLVM tree has done just this. Unfortunately for this immediate problem, they target a whole new intermediate representation. Zack, what tools did you use for the front-end/parser? I've been looking over LLVM but I haven't seen any sign of a parser generator. Yeah, that's where Roberto came in :) We used QLALR which is simply amazing and for those who ever used Bison a lot more convenient than what we had right now. http://labs.trolltech.com/page/Projects/Compilers/QLALR Initially we used QLALR with Flex, then we just went only with QLALR (Flex is really bad when its come to its usage in libraries and there was no real reason for it). If you ever used yacc then you can use qlalr right away. QLALR generated files are simply so much better it was just worth it. I think Roberto could write a book about why QLALR just rocks and it makes sense to use it in this case (granted that the book would have limited audience and I'll let him do that once his back) rather than anything else. In fact I think they've used Roberto's QLALR compiler-generator, which in itself raises some issues about licensing. QLALR is GPL'ed, what is the GPL-status of the sources it generates?? Technically I think by default they inherit the license of the grammar. Now having said that, it's of course up to developer to decide what is the license of the grammar. We'll license everything under the same standard Mesa MIT license. But yeah, the glsl.g grammar that we have there is extremely good, Roberto did a wonderful job and imho it would just make sense to use it with or without LLVM (of course I do love that code so I am very biased). Zack - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Tool to process .syn files?
Zack Rusin wrote: On Thursday 17 May 2007 05:36:45 pm Keith Whitwell wrote: I think the Zack/Roberto LLVM tree has done just this. Unfortunately for this immediate problem, they target a whole new intermediate representation. Zack, what tools did you use for the front-end/parser? I've been looking over LLVM but I haven't seen any sign of a parser generator. Yeah, that's where Roberto came in :) We used QLALR which is simply amazing and for those who ever used Bison a lot more convenient than what we had right now. http://labs.trolltech.com/page/Projects/Compilers/QLALR Initially we used QLALR with Flex, then we just went only with QLALR (Flex is really bad when its come to its usage in libraries and there was no real reason for it). If you ever used yacc then you can use qlalr right away. QLALR generated files are simply so much better it was just worth it. I think Roberto could write a book about why QLALR just rocks and it makes sense to use it in this case (granted that the book would have limited audience and I'll let him do that once his back) rather than anything else. In fact I think they've used Roberto's QLALR compiler-generator, which in itself raises some issues about licensing. QLALR is GPL'ed, what is the GPL-status of the sources it generates?? Technically I think by default they inherit the license of the grammar. Now having said that, it's of course up to developer to decide what is the license of the grammar. We'll license everything under the same standard Mesa MIT license. But yeah, the glsl.g grammar that we have there is extremely good, Roberto did a wonderful job and imho it would just make sense to use it with or without LLVM (of course I do love that code so I am very biased). Sounds good. I've been thinking about LLVM and Mesa a little bit the last few days. If it can be made to work, it seems like a good way to go. There are a couple of practical issues that should be taken into account though: - Firstly, we need to continue supporting the existing drivers. In particular this means we need to generate programs they can understand (ie in the current Mesa IR), up until the point at which they all understand LLVM. - Secondly, I'm not yet convinced that LLVM in its current state really can support the wierdnesses of native GPU architectures. There are some assumptions that seem to be encoded in LLVM that don't apply on GPU's -- things like the availability of a general branch instruction, for instance. On this second level as well, I feel a lot more comfortable with the idea of an intermediate step in this project where the LLVM optimizer targets something like the Mesa IR (or the cleaned up version we have been working on internally) as its initial output, and then look at hardware in a second phase. The thinking for this is: 1) The Mesa IR has many of the characteristics of the hardware ISA's, with supposedly high level GPU/SIMD constructs like IF/THEN/ELSE opcodes as opposed to CPU-world ideas like labels branches. Generating this would be a good validation of LLVM for this work. 2) The i965 is an intricate device to program, especially without docs or a simulator/debugger. The register horizontal/vertical stride and step addressing modes are pretty unique (and confusing), for instance. Going all the way to hardware seems like a big task to do in a single development step. 3) As noted above, we need to get to the mesa IR somehow for other devices. Keith - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Tool to process .syn files?
Zack Rusin wrote: On Thursday 17 May 2007 05:36:45 pm Keith Whitwell wrote: I think the Zack/Roberto LLVM tree has done just this. Unfortunately for this immediate problem, they target a whole new intermediate representation. Zack, what tools did you use for the front-end/parser? I've been looking over LLVM but I haven't seen any sign of a parser generator. Yeah, that's where Roberto came in :) We used QLALR which is simply amazing and for those who ever used Bison a lot more convenient than what we had right now. http://labs.trolltech.com/page/Projects/Compilers/QLALR Initially we used QLALR with Flex, then we just went only with QLALR (Flex is really bad when its come to its usage in libraries and there was no real reason for it). If you ever used yacc then you can use qlalr right away. QLALR generated files are simply so much better it was just worth it. I think Roberto could write a book about why QLALR just rocks and it makes sense to use it in this case (granted that the book would have limited audience and I'll let him do that once his back) rather than anything else. In fact I think they've used Roberto's QLALR compiler-generator, which in itself raises some issues about licensing. QLALR is GPL'ed, what is the GPL-status of the sources it generates?? Technically I think by default they inherit the license of the grammar. Now having said that, it's of course up to developer to decide what is the license of the grammar. We'll license everything under the same standard Mesa MIT license. But yeah, the glsl.g grammar that we have there is extremely good, Roberto did a wonderful job and imho it would just make sense to use it with or without LLVM (of course I do love that code so I am very biased). Zack, could you make your code (at least the parser) available somewhere so I can take a look? One problem with the current GLSL parser in Mesa is that it doesn't report the position (line number) for errors in shaders. The location of each token from the input stream needs to get propogated up to the AST so that errors can be properly reported. It's not a huge deal now because shaders are relatively small, but that'll change. -Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Tool to process .syn files?
Brian Paul wrote: Zack Rusin wrote: On Thursday 17 May 2007 05:36:45 pm Keith Whitwell wrote: I think the Zack/Roberto LLVM tree has done just this. Unfortunately for this immediate problem, they target a whole new intermediate representation. Zack, what tools did you use for the front-end/parser? I've been looking over LLVM but I haven't seen any sign of a parser generator. Yeah, that's where Roberto came in :) We used QLALR which is simply amazing and for those who ever used Bison a lot more convenient than what we had right now. http://labs.trolltech.com/page/Projects/Compilers/QLALR Initially we used QLALR with Flex, then we just went only with QLALR (Flex is really bad when its come to its usage in libraries and there was no real reason for it). If you ever used yacc then you can use qlalr right away. QLALR generated files are simply so much better it was just worth it. I think Roberto could write a book about why QLALR just rocks and it makes sense to use it in this case (granted that the book would have limited audience and I'll let him do that once his back) rather than anything else. In fact I think they've used Roberto's QLALR compiler-generator, which in itself raises some issues about licensing. QLALR is GPL'ed, what is the GPL-status of the sources it generates?? Technically I think by default they inherit the license of the grammar. Now having said that, it's of course up to developer to decide what is the license of the grammar. We'll license everything under the same standard Mesa MIT license. But yeah, the glsl.g grammar that we have there is extremely good, Roberto did a wonderful job and imho it would just make sense to use it with or without LLVM (of course I do love that code so I am very biased). Zack, could you make your code (at least the parser) available somewhere so I can take a look? One problem with the current GLSL parser in Mesa is that it doesn't report the position (line number) for errors in shaders. The location of each token from the input stream needs to get propogated up to the AST so that errors can be properly reported. It's not a huge deal now because shaders are relatively small, but that'll change. http://gitweb.freedesktop.org/?p=users/zack/mesa.git;a=shortlog;h=llvm Keith - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Tool to process .syn files?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zack Rusin wrote: On Thursday 17 May 2007 05:36:45 pm Keith Whitwell wrote: I think the Zack/Roberto LLVM tree has done just this. Unfortunately for this immediate problem, they target a whole new intermediate representation. Zack, what tools did you use for the front-end/parser? I've been looking over LLVM but I haven't seen any sign of a parser generator. Yeah, that's where Roberto came in :) We used QLALR which is simply amazing and for those who ever used Bison a lot more convenient than what we had right now. http://labs.trolltech.com/page/Projects/Compilers/QLALR Initially we used QLALR with Flex, then we just went only with QLALR (Flex is really bad when its come to its usage in libraries and there was no real reason for it). If you ever used yacc then you can use qlalr right away. QLALR generated files are simply so much better it was just worth it. I think Roberto could write a book about why QLALR just rocks and it makes sense to use it in this case (granted that the book would have limited audience and I'll let him do that once his back) rather than anything else. For those of us (e.g., me) not deep in Qt...how the heck do you build qlalr?!? Also, does it only generate C++? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGTegxX1gOwKyEAw8RApPFAKCJpPi+GLvaUN2y4Dk/uCPX21oVPwCePznQ IxuQvSACnz8lt9tsIoW3gik= =ZrvO -END PGP SIGNATURE- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Tool to process .syn files?
On 17/05/07, Brian Paul [EMAIL PROTECTED] wrote:
Ian Romanick wrote:
Is there an easy way in this parser generator to change the grammar for
the TXP instruction? Basically, I want it to be invalid to use TXP with
the SHADOWARRAY2D target.
Michael would have to answer that. Michael?
I will look at it tomorrow.
Alternately, is there a reason we're using this instead of lex yacc?
I think Michael just used what was familiar to him.
I used lex yacc to write a unified parser for another project that
handles ARB_{vertex,fragment}_program (up to vp3 and fp2), the various
NV vertex and fragment programs, and ATI_text_fragment_shader. I could
probably adapt it to work with Mesa without too much trouble.
Opinions?
I guess I'd prefer using standard tools like lexx and yacc. Though, I'd
do research to see if there's anything newer/nicer nowadays.
If my memory serves me right, there was at least one attempt in the
past to kill off those syn files, but they are still alive to this
day.
Ian, if this is no problem for you, feel free to replace it with yacc
grammars, just please keep the old ones #ifdefed for a while, if
possible. The reason I used custom grammar in the first place was that
I wasn't aware of any (not only open source) compiler-compiler (lack
of Internet!) so I just invented one.
--
Pozdrawiam,
Michal Krol
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Tool to process .syn files?
Micha? Król wrote:
On 17/05/07, Brian Paul [EMAIL PROTECTED] wrote:
Ian Romanick wrote:
Is there an easy way in this parser generator to change the grammar for
the TXP instruction? Basically, I want it to be invalid to use TXP with
the SHADOWARRAY2D target.
Michael would have to answer that. Michael?
I will look at it tomorrow.
Alternately, is there a reason we're using this instead of lex yacc?
I think Michael just used what was familiar to him.
I used lex yacc to write a unified parser for another project that
handles ARB_{vertex,fragment}_program (up to vp3 and fp2), the various
NV vertex and fragment programs, and ATI_text_fragment_shader. I could
probably adapt it to work with Mesa without too much trouble.
Opinions?
I guess I'd prefer using standard tools like lexx and yacc. Though, I'd
do research to see if there's anything newer/nicer nowadays.
If my memory serves me right, there was at least one attempt in the
past to kill off those syn files, but they are still alive to this
day.
Ian, if this is no problem for you, feel free to replace it with yacc
grammars, just please keep the old ones #ifdefed for a while, if
possible. The reason I used custom grammar in the first place was that
I wasn't aware of any (not only open source) compiler-compiler (lack
of Internet!) so I just invented one.
I think the Zack/Roberto LLVM tree has done just this. Unfortunately
for this immediate problem, they target a whole new intermediate
representation.
Keith
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Tool to process .syn files?
Keith Whitwell wrote:
Micha? Król wrote:
On 17/05/07, Brian Paul [EMAIL PROTECTED] wrote:
Ian Romanick wrote:
Is there an easy way in this parser generator to change the grammar for
the TXP instruction? Basically, I want it to be invalid to use TXP
with
the SHADOWARRAY2D target.
Michael would have to answer that. Michael?
I will look at it tomorrow.
Alternately, is there a reason we're using this instead of lex yacc?
I think Michael just used what was familiar to him.
I used lex yacc to write a unified parser for another project that
handles ARB_{vertex,fragment}_program (up to vp3 and fp2), the various
NV vertex and fragment programs, and ATI_text_fragment_shader. I could
probably adapt it to work with Mesa without too much trouble.
Opinions?
I guess I'd prefer using standard tools like lexx and yacc. Though, I'd
do research to see if there's anything newer/nicer nowadays.
If my memory serves me right, there was at least one attempt in the
past to kill off those syn files, but they are still alive to this
day.
Ian, if this is no problem for you, feel free to replace it with yacc
grammars, just please keep the old ones #ifdefed for a while, if
possible. The reason I used custom grammar in the first place was that
I wasn't aware of any (not only open source) compiler-compiler (lack
of Internet!) so I just invented one.
I think the Zack/Roberto LLVM tree has done just this. Unfortunately
for this immediate problem, they target a whole new intermediate
representation.
Zack, what tools did you use for the front-end/parser? I've been
looking over LLVM but I haven't seen any sign of a parser generator.
-Bbian
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Tool to process .syn files?
Brian Paul wrote:
Keith Whitwell wrote:
Micha? Król wrote:
On 17/05/07, Brian Paul [EMAIL PROTECTED] wrote:
Ian Romanick wrote:
Is there an easy way in this parser generator to change the grammar for
the TXP instruction? Basically, I want it to be invalid to use TXP
with
the SHADOWARRAY2D target.
Michael would have to answer that. Michael?
I will look at it tomorrow.
Alternately, is there a reason we're using this instead of lex yacc?
I think Michael just used what was familiar to him.
I used lex yacc to write a unified parser for another project that
handles ARB_{vertex,fragment}_program (up to vp3 and fp2), the various
NV vertex and fragment programs, and ATI_text_fragment_shader. I could
probably adapt it to work with Mesa without too much trouble.
Opinions?
I guess I'd prefer using standard tools like lexx and yacc. Though, I'd
do research to see if there's anything newer/nicer nowadays.
If my memory serves me right, there was at least one attempt in the
past to kill off those syn files, but they are still alive to this
day.
Ian, if this is no problem for you, feel free to replace it with yacc
grammars, just please keep the old ones #ifdefed for a while, if
possible. The reason I used custom grammar in the first place was that
I wasn't aware of any (not only open source) compiler-compiler (lack
of Internet!) so I just invented one.
I think the Zack/Roberto LLVM tree has done just this. Unfortunately
for this immediate problem, they target a whole new intermediate
representation.
Zack, what tools did you use for the front-end/parser? I've been
looking over LLVM but I haven't seen any sign of a parser generator.
In fact I think they've used Roberto's QLALR compiler-generator, which
in itself raises some issues about licensing.
QLALR is GPL'ed, what is the GPL-status of the sources it generates??
If they are GPL, that's a problem...
Keith
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Tool to process .syn files?
On 5/16/07, Ian Romanick [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Where is the tool to process the .syn files in src/mesa/shader?
Is there an easy way in this parser generator to change the grammar for
the TXP instruction? Basically, I want it to be invalid to use TXP with
the SHADOWARRAY2D target.
Alternately, is there a reason we're using this instead of lex yacc?
I used lex yacc to write a unified parser for another project that
handles ARB_{vertex,fragment}_program (up to vp3 and fp2), the various
NV vertex and fragment programs, and ATI_text_fragment_shader. I could
probably adapt it to work with Mesa without too much trouble.
Opinions?
Personally I'd rather see a Lex and Yacc parser instead of something custom...
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
