> 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?
Yes, but there are many many differences. I initially looked at the IIR spec, but I haven't closely followed it. > (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) Yes, I fear that verilog is too different from VHDL. > 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? I don't remember where the name comes from. It was developed for GHDL, and therefore it has some uniq features: strong typing, nested subprograms, overflow checking... > 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. There are some documentation in the specs. > 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. Yes, having different layers was useful for debugging. > (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?) Yes, potentially. But the runtime must be adapted for verilog too. > 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... Again, I don't remember the story of the name. I have written it a few years later (maybe in 2003) Mcode code generator is rather stupid but very fast. > (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?) I simply visited Sokcho in 2002. Tristan. _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
