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 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Jul 23 12:28:33 2014
This archive was generated by hypermail 2.1.8 : Wed Jul 23 2014 - 12:29:23 PDT