On Sun, 2014-01-12 at 04:57 +0100, [email protected] wrote: > > Or something similar. The remaining Ada files are without a comment > > header. I am curious to know the history of GHDL. When, How, Why did > > the project start? Was there any funding or support?
> So to understand better VHDL, I decided to write a simulator. Because > I also wanted to train myself in Ada and because VHDL derives from Ada, > I have written it in Ada. I think I started in 1998. > > In 2002, GHDL was complete enough to simulate many designs, so I release > it. > > > Shock and awe aside for a moment, is there an architecture document > > and an API/ABI document? > > No. I am used to saying it has the classical architecture of a compiler: > lexical analysis (scanner.adb), parser (parse.adb), semantic analysis > (sem*), and code generation (translate.adb). Ok, I agree that doesn't > help a lot :-) This is as I have discovered through reading the source, and seeing that does help a lot, but still leaves me unclear on, for example, where in the source elaboration happens. A few supplementary questions, if it's OK to ask: 1) IIR is the Internal Intermediate Representation, as described in for example www.eda.org/VIUF_proc/Fall96/WILLIS96C.PDF right? (from which, if someone really wanted Verilog, perhaps they could write or adapt a Verilog parser to generate an IIR tree, and we can help them feed that IIR tree into ... I'm guessing, some entry point into Translate, right? But IIR is VHDL-specific and might be too high level a target for Verilog) 2) Ortho Now IIR is translated into "ortho" code which is common to gcc, mcode and potentially LLVM backends : but how did "ortho" get its name? Is it another recognised standard, or the result of a University compiler project with some existence outside ghdl, or is it specifically developed by Tristan for ghdl? It seems to me that a low-level intermediate representation (as "ortho" seems to be) with three independent code-generation backends could be a powerful tool for other compiler writers if it was better understood and perhaps even documented. And as I understand it, ghdl1-debug writes ortho to file, and oread-gcc is a thin layer which reads it and converts to gcc (Gimple) IR and passes that to gcc to compile. Which makes "ortho" fairly transparent and (relatively) easy to work with and debug. (And perhaps THIS is the route for adding Verilog : a lower level representation, closer to the backend : adapt Icarus to generate Ortho code, write it to file, and run that file through oread-gcc to generate objects for each Verilog entity*cough*module, then let ghdl -e stitch the lot together. Could that potentially work?) Disclaimers : (a) I am not suggesting Tristan should do any of this, beyond advise whether or not this is on the right track, and (b) I have no interest myself in Verilog beyond the fact that some sim models are Verilog only nowadays; I recently had to trawl the web for a VHDL SDRAM model that has been DELETED from the manufacturer's own website) (3) Mcode Then we have mcode ... ghdl's own JIT compiler. Same questions : is there a story behind its name? Independently developed for ghdl, or adapted from another project? Once again, IMO it's a remarkable achievement to make a JIT compiler run within 20% (one test only) of the speed of a much more complex optimising compiler's backend... (4) And lastly, not so technical (if it's personal, no need to answer :) Sokcho and Dunoon have something in common, being seaside towns. I live in one, but is there a story behind the other being ghdl's home for so long (and probably again from 0.32 or 0.33?) - Brian _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
