kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 09/05/2013 12:03 PM, Lorenzo Marcantonio wrote:
> On Thu, Sep 05, 2013 at 11:02:36AM -0500, Dick Hollenbeck wrote:
>> Says you.   Says me:  having the the bits in the instance block matter.
>>
>>
>> I guess if what I have to say is going to be labelled as irrelevant right out the box, I'd
>> be wasting my time continuing.
> 
> Strange that, said by someone which a little while ago told that data
> could even be on the moon and it's all a question of interface... I'd
> like you to notice that in my first message I was concerned about
> performance of an object vs a simple integer. These things should be a)
> readily copyable and b) readily passed around by value, from the common
> usage pattern I've seen.
> 
>>From a performance standpoint I'd roughly evaluate the implementations (both in
> space and in time) in this order: int, std::bitset<>, std::vector<bool>,
> std::set<int>. The adhoc implementation should be roughly on par with
> bitset. 


Agreed, I estimate the same.


> 
> However, what I meant was that there were 'bigger' proposals on the list
> to evaluate. Something like std::bitset (i.e. something inherently
> configured and limited at compile time) clearly is not adequate for
> these proposals.



I think Tom's class is adequate. I don't think Brian S.'s idea about dynamically
assignable layer slots is optimal.  I think fixed layer slots are easier to code, but I
don't see why you have to limit the number of slots with Tom's approach.  You can have 300
layers if you want, but I think you need to pre-assign all of them, and chose not to use
but a subset of them on any board.

I think fixed technical layer names are important, both to KiCad branding and to board
merging like JP mentioned.  Because these names are being indexed by google.

KiCad branding comes about via help with google and propagation of opensource boards and
pretty footprint libraries.

This is part of why I don't want to mess with the technical layer names that are in place
already and why I yanked the international language translations for them.  *Adding* to
that established list with concise English names is not a problem for me.  The footprint
format, at least pretty, should not be viewed as forever fixed.  However the keywords we
have already chosen should not be changed, while remaining open to significant additions
to it.


Some observations:

a) specctra numbers copper layers from front to back, starting from zero.


b) in contrast, my most recent conversations with bare board houses in China had them
numbering layers from back to front, starting at 1 on the back.


c) The internal copper bit masks for layers has always bothered me, the sequence that is.


d) Existing problematic code fragments should be identified early in the planning phase,
and any design change should be evaluated on its ability to handle the problematic code
collection.  Please start that problematic list with where I output the pretty layers, and
extend it by adding to it.


It seems to me we could go with a conceptual enumeration embodied in Tom's FLAG_SET
template, where the enumeration starts at zero and goes on up forever if need be.
Although you pick the end of the range with a compiled in number, that is pertinent until
it is inadequate.

If the result of the first implementation is that you do not depend on layer numbers
(much), but rather on names or range checking, then you can shift that enumeration at any
time in the future without causing the source code or existing data files any grief.


For for the sake of discussion, I propose as one possibility:

0 - 31 are cu layers

32 - MAX_LAYER   are technical layers.


These LAYERs and LAYER_SET are done using "Tom's 20 minute solution plus augmentation, as
needed".


If you have based your files on concise English names for all but the Cu layers, but those
cu layers are also named, then I don't see any large grief to shift this conceptual
enumeration which runs from 0 - MAX_LAYER.  Not only can you make MAX_LAYER higher, but
you can also shift regions of interest within it without radically impact code or data
files later.


Dick



> 
> std::set<int> (usually a balanced tree) is the bigger and slower and
> IMHO only would have a meaning if we allowed arbitrarily large and
> sparse layer numbers. std::vector feels a good compromise. An
> std::bitset<> or a int64_t would be useful if we put a cap of maximum 64
> or whatever number of simultaneous layers. With an 'adequate' layerset
> structure that could be arranged.
> 
>