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

View options for component fields. #24

Open
perlindgren opened this issue Jul 14, 2023 · 1 comment
Open

View options for component fields. #24

perlindgren opened this issue Jul 14, 2023 · 1 comment

Comments

@perlindgren
Copy link
Owner

Problem.

As of now there is no defined way to determine the preferred formatting of Signals e.g., when displayed in a tooltip, or by the popup hover.

Potential solution.

We could define an enum:

enum SignalFmt {
  Unsigned(u8), // u8 {1,2,4}
  Signed(u8), // u8 {1,2,4}
  Hex(u8), // u8 {1,2,4} 
  Bool, // treats it as true/false
  Binary(Vec<(u8), Id)>) // u8 is the number of bits for each field, where Id is a string for the field name
}

Then we can implement a helper that takes a Signal, and a SignalFmt and formats the signal accordingly.
Maybe the Binary is a bit OTT, and would likely take a lot of space, and would not align well in a table with the other formats, which are all compact.

In the model we associate each output to a SignalFmt.

Alternatively instead of the u8, we can have it structured:

enum SignalSize {
  B, // byte
  H, // halfword
  W, // word
  D, // double word
}

But that sort of restricts to 32 bit architectures (though D could be used to express 64 bits, but signal is currently fixed to 32 bits in any case ...).

Another potential structure is to go with:

enum SignalFmt {
  U8,
  U16,
  U32,
  I8,
  I16,
  I32,
  HexU8,
  HexU16,
  HexU32,
  Bool, // treats it as true/false
  Binary(u8) // just to set a limit to the number of bits
}

Signals that have very specific implementation, like the register numbers 0..31 in MIPS will require side stepping this formatting, so its up to the component to use this extra info or not (when creating the popup/tooltip and internal View).

Any thoughts on this. We can discuss here in the issue and/or on discord.

@perlindgren
Copy link
Owner Author

Personally I think the last one is pretty straightforward and intuitive.

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

No branches or pull requests

1 participant