Doesn't a queue sometimes have more overhead in terms of simulation performance? If additions and deletions mainly occur at the ends of the "list" then a queue may be as efficient, but if a lot of operations take place in the middle of the list, I would expect the linked list to be more efficient, since elements are being moved around. Neil Gordon Vreugdenhil wrote On 04/03/06 13:49,: > In Appendix D, List is described as being a 'include of a set of > parameterized class definitions. This appears to be a flawed > approach due to how parameterized class specializations are > defined in 7.23. > > Consider: > > ------ file p.sv > package pkg; > 'include <List.svh> > function void dump_list(input List#(int) thelist); > ... > endfunction > endpackage > > ------ file top.sv > > module top; > import pkg::*; > > 'include <List.svh> > List#(int) mylist; > .... > initial pkg::dump_list(mylist); > endmodule > > This will fail. The **included** parameterized class > definitions create two "universes" of incompatible types; > the specialization inside top and the one inside pkg are > different types. Moving the 'include in top.sv outside > of the module still doesn't help since then the > parameterized class (and its specializations) are bound > to the $unit and are not shared with the ones in > package pkg. > > > It isn't obvious that List is really needed in SV; > queues have closely related functionality that it doesn't > seem that List presents that much additional functionality -- > a few additional methods (swap, etc) but it isn't obvious > that we should retain it at all. > > If we do want to retain List, at the very least the List type > should move to package std so that the type specializations > can be usefully shared through the design (which I expect was > the original intent). > > Gord -- --------------------------------------------------------------------- Neil Korpusik Tel: 408-720-4852 Senior Staff Engineer Fax: 408-720-4850 Frontend Technologies - ASICs & Processors (FTAP) Sun Microsystems email: neil.korpusik@sun.com ---------------------------------------------------------------------Received on Mon Apr 3 17:27:43 2006
This archive was generated by hypermail 2.1.8 : Mon Apr 03 2006 - 17:27:59 PDT