>>> On 31 May 2012 at 07:03, Jim Lewis <Jim@synthworks.com> wrote:
> Hi Martin,
>> I'm taking a look at implementing an associative array in VHDL - which raises
> a number of questions about the fundamental requirements, and some on
> possible APIs.
>> Requirements questions
>> ================
>>
>> 1) Is it important that the accesses be ordered (so you can iterate over
> the key, value pairs in a consistent order every time)? For example, Python's
> (and I think Perl's) dictionaries are
>> unordered. C++ std::map is ordered, std::hash_map is unordered.
>>
>> ...
>
> I think the method interface is more important than the implementation.
Quite so - but whether the keys are presented in a predictable order is a key (sorry!) part of the interface. However... see further on:
> One of the things that we have seen a need for with some of the packages
> David Bishop is working on is named packages that are selectable on a
> design unit by design unit basis.
>
> Perhaps we need the same type of capability with protected types.
> That way we could have an ordered and non-ordered implementation
> that could be selectable by selecting the PT body some how. It
> is a good time to think about this as I am also thinking we need
> generics for protected types and I would want the two capabilities
> to play nicely with each other.
>
> If we had this, then we could have a body that does unordered lists
> and one that does ordered lists.
Having done some more thinking, I think the ordered approach is more suitable for us. A very powerful argument in that direction is that it requires only that the "datatype to be keyed" has a "<" operator defined, whereas the unordered version requires a "suitably good" hashing operator to be defined for each type we want to key off - which also requires different implementations per type...
This would allow ints, chars, strings, unsigned, real etc to work "out of the box" and the user can provide an overloaded function for any custom types that they create. It doesn't have to match any mathematical concept of size, just a consistent set of ordering rules. The one downside is that std_logic_vectors couldn't be used as keys without either casting them to unsigned (or using ieee.numeric_unsigned - does that define "<"?)
>
>
>> What should the API look like?
>> ====================
>>
>> ...
I assume the rest of it looked sensible then :)
> >
>> Serialisation
>> --------------
>> Would we like to be able to serialise this (and other) new data-types we
> create?
>>
>> a.read(file)
>> a.write(file)
> Yet another use model that supports the need for PTs to
> allow file identifiers as a parameter.
>
:)
> What do other languages do?
>
Python has a module which can serialise anything. C++ has a boost item which has a similar intent, but I've never used it.
To be honest, those are functions which can be added later I imagine.
Cheers,
Martin
-- Martin Thompson CEng MIET TRW Conekt, Stratford Road, Solihull, B90 4GW. UK +44 (0)121-627-3569 : martin.j.thompson@trw.com http://www.conekt.co.uk/ Conekt is a trading division of TRW Limited Registered in England, No. 872948 Registered Office Address: Stratford Road, Solihull B90 4AX -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu May 31 00:47:36 2012
This archive was generated by hypermail 2.1.8 : Thu May 31 2012 - 00:48:00 PDT