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

Support parameterized types in the DSLX-to-C++ transpiler #445

Open
RobSpringer opened this issue Jun 9, 2021 · 2 comments
Open

Support parameterized types in the DSLX-to-C++ transpiler #445

RobSpringer opened this issue Jun 9, 2021 · 2 comments
Labels
blocker Blocking design work dslx DSLX (domain specific language) implementation / front-end long-term-enhancement Issues that are sensible enhancements but XLS devs expect may not be addressed in the near-term

Comments

@RobSpringer
Copy link
Contributor

(Note that I'm currently working on said transpiler)

On the first pass, we won't support instantiating parameterized types in the transpiler, because A) my use cases don't need it, and B) its hard, but it would be good to have. It'd require some thought as to what we'd be targeting and how we'd want to expose this to a user - are we targeting the JIT? Then we could emit fully instantiated parametrics. Would we be targeting arbitrary usages? Then we'd want...templatized C++ types? Or regular C++ types that could be size-adjusted dynamically?

Not a trivial task.

@cdleary
Copy link
Collaborator

cdleary commented Nov 2, 2022

Note the transpiler is just for types, not for functions/expressions. It lives in https://github.com/google/xls/blob/main/xls/dslx/cpp_transpiler_main.cc -- maybe we should move it to the tools/ directory for consistency/discoverability.

@cdleary cdleary added dslx DSLX (domain specific language) implementation / front-end long-term-enhancement Issues that are sensible enhancements but XLS devs expect may not be addressed in the near-term labels Nov 2, 2022
@lpawelcz
Copy link
Contributor

lpawelcz commented Nov 7, 2023

@proppy This would be super useful in our work on Zstandard codec.

In #1167, #1168 and in future work we want to provide C++ tests that process data with libzstd and compare the results against simulation of our zstd blocks.
However we are concerned about readability of the syntax used for specifying data for our DSLX structures. For example for FrameHeaderResult structure it looks like this:

      Value::Tuple(
          {/*status:*/ Value(UBits(0, 2)),
           /*header:*/
           Value::Tuple(
               {/*window_size:*/ Value(UBits(0x1234567890ABCDEF, 64)),
                /*frame_content_size:*/ Value(UBits(0x1234567890ABCDEF, 64)),
                /*dictionary_id:*/ Value(UBits(0xCAFE, 32)),
                /*descriptor:*/
                Value::Tuple({/*frame_content_size_flag: */ Value(UBits(3, 2)),
                              /*single_segment_flag: */ Value(UBits(1, 1)),
                              /*unused: */ Value(UBits(0, 1)),
                              /*reserved: */ Value(UBits(0, 1)),
                              /*content_checksum_flag: */ Value(UBits(0, 1)),
                              /*dictionary_id_flag: */ Value(UBits(2, 2))})}),
           /* buffer:*/
           Value::Tuple({/*contents:*/ Value(UBits(0, 128)),
                         /*length:*/ Value(UBits(0, 32))})})

It is not that hard to make a mistake and provide incorrect data. Because of that we wanted to write C++ structs that will map into our DSLX structures and provide a cleaner and less error-prone way of specifying test data. Then we discovered cpp_transpiler which does this for us by generating struct definitions, ToValue() converters and ToString() methods which are really useful for debugging. Sadly, we encountered some blockers.

One of them is lack of support for parameterized types. For example, our buffer type cannot be used for generating C++ structs because of BSIZE parameter.
We would greatly appreciate having this feature, please let us know what do you think about that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocker Blocking design work dslx DSLX (domain specific language) implementation / front-end long-term-enhancement Issues that are sensible enhancements but XLS devs expect may not be addressed in the near-term
Projects
Status: No status
Development

No branches or pull requests

4 participants