Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unpack no longer warns #2397

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

unpack no longer warns #2397

wants to merge 2 commits into from

Conversation

rowanG077
Copy link
Member

@rowanG077 rowanG077 commented Jan 4, 2023

FIXED: Clash no longer gives Dubious primitive instantiation warning when using unpack #2386.

unpack will never go through fromIntegral during synthesis.

Fixes: #2386

Still TODO:

  • Write a changelog entry (see changelog/README.md)
  • Check copyright notices are up to date in edited files
  • Let CI run for GHC < 8.8
  • unit test

@rowanG077 rowanG077 force-pushed the fix-2386 branch 4 times, most recently from 4f99788 to 06b8b75 Compare January 4, 2023 17:55
FIXED: Clash no longer gives `Dubious primitive instantiation warning`
when using `unpack` [#2386](#2386).
@rowanG077
Copy link
Member Author

The blackbox for unpackCUShort# doesn't get triggered. It uses the generic path. I'm not sure why this is the case.

@rowanG077
Copy link
Member Author

Please run the full test suite. I couldn't get tests to run.

@alex-mckenna
Copy link
Contributor

CUShort is a newtype and was probably just ripped apart by Clash (since it still doesn't properly support casts). For the other types like Int8, they use data (and did when they were just Int and not the new fixed-width primitive types) so they would be hit in the evaluator.

Copy link
Member

@martijnbastiaan martijnbastiaan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not entirely convinced this would pass CI, even after fixing the wrong-name issue it encounters now (see comment). Feel free to use the GitLab runners to run the tests. To safe some resources you could temporarily comment:

tests-8.6:
extends: .common-trigger
variables:
GHC_VERSION: 8.6.5
MULTIPLE_HIDDEN: "no"
tests-8.8:
extends: .common-trigger
variables:
GHC_VERSION: 8.8.4
tests-8.10:
extends: .common-trigger
variables:
GHC_VERSION: 8.10.7
tests-9.0:
extends: .common-trigger
variables:
GHC_VERSION: 9.0.2

, $(lift (pack w64))
, $(lift (pack cu))
)
, ( $(bLit "0000000000000000000000000000000000000000000000000000000110100101")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
, ( $(bLit "0000000000000000000000000000000000000000000000000000000110100101")
, ( 0b0000000000000000000000000000000000000000000000000000000110100101

Shouldn't this just work?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You'd have to do annotate each one with its size: 0b.... :: BitVector n

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was hoping type inference would take care of that as they're mentioned in topEntity. Right nvm, it is all packed.

| [DC _ [Left arg]] <- args
, eval <- Evaluator ghcStep ghcUnwind ghcPrimStep ghcPrimUnwind
#if MIN_VERSION_base(4,16,0)
, mach2@Machine{mStack=[],mTerm=Literal (Int8Literal i)} <- whnf eval tcm True (setTerm arg $ stackClear mach)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
, mach2@Machine{mStack=[],mTerm=Literal (Int8Literal i)} <- whnf eval tcm True (setTerm arg $ stackClear mach)
, mach2@Machine{mStack=[],mTerm=Literal (Int8Literal i)} <-
whnf eval tcm True (setTerm arg $ stackClear mach)

Keeps the line limit sensible

Comment on lines +11 to +13
type: 'packInt16# :: Int16
-> Bitvector 16'
template: ~ARG[0]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I doubt this is true for VHDL. Aren't Ints typed as signed?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was also under the impression int is signed and word is unsigned in netlist / HDL

@martijnbastiaan
Copy link
Member

@rowanG077 Do you intend on finishing this PR? :)

@rowanG077
Copy link
Member Author

@martijnbastiaan A yeah. I definitely want to finish this. It totally slipped my mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Derived BitPack instance introduces Dubious primitive instantiation warning
4 participants