Hi Ryan, Would you be willing to start a proposal on this? Jim > I'll put the conclusion here at the top for impatient people like me. It all boils down to "long /= wrong". And I'm not asking for the only-right-and-best-possible 'image. Just a good, general, easy-to-describe 'image. > > > On 22 Jul, at 9:21 pm, David Koontz <diogratia@gmail.com> wrote: >> On 23 Jul 2014, at 6:28 am, Jim Lewis <Jim@synthworks.com> wrote: >>> My only point in noting your non-LRM short cuts is that they are natural to >>> do and if you really want to use 'image then you might want to make that a >>> proposal. >> >> records of records of records, ..., oh my! >> >> Why is it you don't have printf type string conversion formats for entire >> structures or unions in the C programming language? You could note Ada >> doesn't generate image strings for values of non-scalar types either. >> >> It boils down to no one actually needing an entire (and potentially almost >> unlimited) record or array image on a single line or as a single string. > > Martin pointed out that Python has this. Ruby has a couple ways to do this. > Java has something similar. Unfortunately, that exhausts the "modern" > programming languages I know. > > Good point on Ada. I neglected to check to see if this facility existed there. > >> Making something simple to use is encouraging it's use without regard to the >> actual 'cost'. Sort of like multidimensional arrays going to waveform dump >> files. > > Sure, I log multidimensional arrays to waveform files regularly. Yes, they > slow down my simulation, sometimes significantly. But it takes much, much more > time for me to pore over code trying to find a problem without any feedback > than it does to log large amounts of data. Otherwise I'd just take my FGPGA > design to the lab after every code change. It runs so much faster in the lab! > > Please, let me as the designer make the tradeoffs instead of enforcing them in > the language. I'm not asking for slow things to be fast. I'm asking for easy > things to be easy. No language can make a bad programmer into a good > programmer, so trying to decide "holy" and "evil" constructs at a language > level is usually a bad thing. I realize VHDL already has a good deal of this; > safety and robustness are highly valued, encouraged, and supposedly enforced. > Sort of like external names: I never use them in synthesizable code, but I use > them in almost every test bench I write. > >> The pain of expressing all those record elements by individual image >> conversion makes a nifty reminder not to do something dumb. For those >> burdened by that perhaps a smarter text editor is in order instead of gumming >> up the language. > > No, actually it's just pain. Perhaps I'm too software-ish like Martin in that, > if there is an easy way for a computer to do a general task, I'll start with > that. > > If I'm wrong, I hope someone will correct me: I'm guessing this change will be > 1-3 LRM sentences and one or two new, relatively short function/method calls in > a compiler. > >> Or can someone figure out how to place meaningful limits when you've >> expressed the ability to 'image a record type that can contain elements of >> record types? > > The obvious limits are at the scalars that must be the leaves of any composite > data type. When you write a compiler, you choose limits. (Again, Tristan and > others please correct me where I'm wrong.) Or you design the compiler so the > limits are externally imposed, e.g. virtual memory size, hard disk capacity. > Sometimes my programs exceed these limits. All I ask for is a meaningful > warning or error message (doesn't have to be a VHDL report) letting me know > what happened so I can rework my approach. > >> Even an array type can suffer from image string length accumulation. A >> string can have a natural length, a quarter of the character values have >> multiple character enumerations (non-printable characters or graphic >> characters that are format effectors). Not to mention Ryan's proposed string >> length expansion: >> >>> -- Will print "('0','1','1')" according to my suggestion. >> >> Which will increase the length associated with printable graphics characters >> three fold. >> >> variable a: std_logic_vector (0 to natural'high/4) := (others => '0'); >> ... >> a'image -- (It was those opening and closing parentheses) >> >> would run out of string length and there aren't any VHDL standard defined >> error messages to get the point across to the neophyte VHDL user. > > OK, you make several points here. > > (1) Arrays alone have this problem, so if we're going to do arrays, we might as > well do records. (Maybe this isn't your intended point, but it's what I > got. :-) > > (2) My proposed format is not the shortest possible. Granted. I'm aiming for > something familiar, unambiguous, reasonably balanced between brevity and > readability. Canonical representations don't have to be the best. That > doesn't convince me that we shouldn't have one. > > (2a) Good use case for when we might want to have an overloadable to_string. > Bit string literals are typically much easier to interpret with than > comma-separated lists of characters. > > (3) The LRM doesn't define standard tool error messages. Rightly so. When my > compiler hits one of its limits, I want to define my own error message. As far > as I know, the LRM doesn't say anything about what a tool should print to a > transcript or error log or what. These are tool-dependent issues. > > (4) Variation on the previous idea: the LRM doesn't define error messages for > limitations not specified in the LRM. It doesn't and it shouldn't. In other > words, when the implementation imposes a limitation for speed, efficiency, > complexity, whatever, then the implementation needs to come up with its own > feedback mechanism. > >> We had someone actually do a natural range std_logic_vector recently, and it >> spawned all sorts of new (previously missing) diagnostics in a couple of open >> source VHDL tool implementations. It's legal in VHDL just like record >> elements that are record types. > > Yes! VHDL is already "unbounded" in many ways. The STRING type is pretty > long. The LRM doesn't limit how long a scalar/enumerated identifier can be. I > can define a scalar type with a value that's a bunch of A's in a row. Even > NATURAL'HIGH/4 of them. That's a long line of text in a large file. Calling > 'image with an object that has that value should give a long string. > >> I think a proposal may be in order for either package or attribute >> implementation. And if you can't make it workable as a function in a package >> it's probably not going to be useful as an expansion to the 'image attribute. >> >> And ya, the design specification would ugly as all get out, but I think it's >> doable with present predefined attributes. > > I think I don't understand you. It's easy to write this as a function for any > particular array or record type. So a record-of-records-of-... type would > simply call the to_string function for its fields, and they would call > to_string for their fields, etc. Since we can't (currently) loop over fields > in a record, I can't write executable code that works for all types. Pseudo-code > is easy. My original proposal used a sentence or two. > > function to_string(a : anonymous record) is > variable str : string; > begin > foreach field in a'type loop > str := str & to_string(field); > end loop; > return str; > end function to_string; > > (Yes, I know I'm taking lots of shortcuts here; it's pseudo-code.) Arrays are > similarly easy in pseudo code. The trick in executable code is that VHDL > doesn't have a way to iterate over all the elements of an array with an > arbitrary number of arbitrary-typed indices. > > Am I missing your meaning? > >> While I don't mind someone getting frustrated after being inspired to encode >> an entire database into a record hierarchy the implementation might at least >> owe some meaningful diagnostics instead of simply an error notice and a line >> number when trying to express that record hierarchy (or long array) as a >> string. > > Again you lost me. Your comment does remind me, though, that the safest way > (hence recommended) to transfer or backup a MySQL database is a text dump to > file. The text dump consists of regular old SQL statements to create and > insert records into the database. Kind of like using VHDL aggregate format to > dump the value of a record-type object. > >> Monitoring the length would complicate the package function somewhat but >> likely beats the heck out of trying for a standardized error message (of >> which VHDL has none to date) for the 'image attribute. > > Still lost. If/when I'm writing a to_string function for a particular record > type (i.e. executable, not pseudo-code), I'm not going to track the length. > I'll let the simulator/synthesizer/elaborator tell me when I reach > STRING'length or their implementation limits. > >> I'm personally skeptical of doing a 'image attribute on things that can't be >> expressed in a string when the language allows the type declaration. Your >> simply serving a subset of the potential uses. There is no similar >> limitation elsewhere which sort of screams scalar limitation. > > Still lost. VHDL code is a sequence of characters/bytes. I don't see what > can't be expressed in a string. > > There are several other places where I think the type system is unnecessarily > limited. > > http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/RelatedRecords > http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/CompositesProtectedTypes > http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ArbitraryIntegers > http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/InitObjectSizing > http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/RangeOperations > http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/RecordMemberAttribute (personally conflicted on this one) > http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/EmptyRecord > http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ExternalNameTypes > > There are several more related to protected types as well. > >> And if you do give it to them, next will be 'VALUE (a natural symmetry). > > Exactly. We've already suggested that. I'm planning to include it in my > proposal. > > It's strange how your arguments against the idea sound to me like natural, unsurprising features or even benefits of the idea. > > - Ryan > > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Jim@SynthWorks.com VHDL Training Expert http://www.SynthWorks.com IEEE VHDL Working Group Chair OSVVM, Chief Architect and Cofounder 1-503-320-0782 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Jul 23 21:25:24 2014
This archive was generated by hypermail 2.1.8 : Wed Jul 23 2014 - 21:25:25 PDT