search

forsyde / forsyde-deep

Other
1 stars 2 forks source link

[CLOSED] Synthesis of FSVec #23

Closed HWoidt closed 8 years ago

HWoidt commented 8 years ago

Issue by ingo-sander Friday Dec 25, 2015 at 14:50 GMT Originally opened as https://gits-15.sys.kth.se/ingo/forsyde-deep/issues/23

There seems to be a problem with the synthesis of FSVec, which becomes visible in the SimpleDES_HW.hs example. The normal 'compileQuartus', which synthesizes the fSys-subsystem works, but there is a problem with the full example, where FSVec D5 Bit cannot be synthesized.

Check the code below:

ingo@hsv:examples> ghci SimpleDES_HW.hs GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling SimpleDES_HW ( SimpleDES_HW.hs, interpreted ) Ok, modules loaded: SimpleDES_HW. _SimpleDES_HW> compileQuartussubkeysSys ** Exception: VHDL Compilation Error: Unsupported type FSVec D5 Bit in process function subkeys_0' (created in SimpleDES_HW) used by processsubKeys' belonging to system definition `genSubkeys' (created in ) *SimpleDES_HW> :q Leaving GHCi.

HWoidt commented 8 years ago

Comment by HWoidt Wednesday Feb 03, 2016 at 17:33 GMT

This problem is due to the fact that we want to use TypeRep and TyCon for identifying types during translation. This means we need to be able to generate TypeRep and TyCon objects from TH Name objects. Unfortunately since ghc-7.8 this needs the PackageId which is a some hashed stuff that you can't guess.

This specific issue is fallout from the naive fix I applied in 9dc94313 and other previous changes that tried to treat the symptoms of the above problem. What happens is, that TyCon for the correctly instantiated FSVect is used for registering the known type for translation, while the TyCon generated by TH is used for querying during compilation. Since the latter object misses the Pkg value, they do not match.

After reading the below references, I conclude that this is a whole mess, and even if we fix it now, this will break immediately on ghc-7.12 as the whole runtime type information topic is totally in flux. The best solution is see right now is to define our own type-rep that implements the smallest common denominator of the information that can be gathered from TH.Name, Data.Typeable and Data.Data, which would be the qualified name of "Module.Submodule.Name".

Upsides

Downsides

Possibly relevant tickets and wiki pages: https://ghc.haskell.org/trac/ghc/ticket/7897 https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/PolyTypeable https://ghc.haskell.org/trac/ghc/wiki/Typeable

stuff to monitor for the future https://ghc.haskell.org/trac/ghc/ticket/10068 => To quote the above: "This is madness!" runtime type information is a huge mess -.- https://ghc.haskell.org/trac/ghc/ticket/10343 and another one...

historically related but not directly relevant: https://ghc.haskell.org/trac/ghc/ticket/3480 https://ghc.haskell.org/trac/ghc/ticket/5568

HWoidt commented 8 years ago

Comment by ingo-sander Wednesday Feb 03, 2016 at 19:00 GMT

1) Does the current ForSyDe version work in ghc 7.8.4?

2) How long time would it take to implement an own type representation?

3) You pointed out that the runtime type information seems to be unstable even in ghc-8.0? Is this correct? Is there some hope for a more stable solution? Why did they change it in 7.10.3?

HWoidt commented 8 years ago

Comment by HWoidt Wednesday Feb 03, 2016 at 22:50 GMT

1) I just tried and there is a compile error due to import of Traversable. This is probably related to the "Burning Bridges Proposal" [1] which was accepted in 7.10. This should be easily fixable though. I will look into it tomorrow and see whether there are any more issues. What is the priority on this?

2) I expect to work on this and finish it tomorrow.

3) There is a lot of recent discussion going on in some of the tickets I linked above because TypeRep is used for safe casting and any inaccuracy in the automatic derivation of these instances in ghc allows the "implementation" of the infamous "unsafeCoerce" i.e. circumventing all compiler checks, even in the Safe-Haskell mode. Because of some issues in that area, there is discussion of adding additional fields to the TyCon type. Since we need to manually instantiate objects of this type and the information we can gather from TH.Name is not enough for correctly instantiating the objects already, I expect this to not get any better in the future.

As to why this module was changed: The whole Typeable module was completely reimplemented for the Polymorphic Typable [2] in 7.8, and the old implementation was deprecated and subsequently removed in 7.10

[1] https://wiki.haskell.org/Foldable_Traversable_In_Prelude [2] https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/PolyTypeable

HWoidt commented 8 years ago

Comment by HWoidt Wednesday Feb 03, 2016 at 23:21 GMT

Some discussion on Package-names,-keys and -ids from the TH perspective (just for reference): https://ghc.haskell.org/trac/ghc/ticket/10279 to quote one of the developers: "The whole package [template-haskell] is a mess."

HWoidt commented 8 years ago

Comment by ingo-sander Thursday Feb 04, 2016 at 09:26 GMT

If you can fix 2) then 1) is of lower priority. Still, it would be good to have because many people still run ghc 7.8.4 and I suspect this will also be an important version in the future.

Regarding 3) this is an awful message. We all should learn from it in the future and try to avoid non-standard methods.