← Back to team overview

kicad-developers team mailing list archive

Re: Experiments and considerations for more layer

 

Lorenzo,

On Tue, 03 Sep 2013, Lorenzo Marcantonio wrote:

> On Mon, Sep 02, 2013 at 08:55:31PM -0600, Brian F. G. Bidulock wrote:
> > that's another 26 (or more) layers.  Still think 64 will be
> > enough?
> 
> I said it was a mid-term solution.

Mid-term in the wrong direction.  Kicad is like that...

> > BTW, long long is part of the C standard and excluded from the C++
> > standard.  Good luck with Windows (it doesn't support it in C++).
> 
> int64_t is in the standard. And mingw supports long long on windows
> anyway...

If you consider gcc-specific features a standard...

> > The best approach is to make the layer a full class and only use
> > accessor functions, or overload the bitwise logical and arithmetic
> > operators.  I did that, but nobody was interested at the time.
> 
> If you re-read my first message that would be the long term plan anyway.
> How did you represent literals? What about the missing compiler
> folding? These things are used a lot, there could be performance
> implications.

If you take a look, most bitmask comparisons are determining whether
a layer number is a copper layer or not.  For things like holes, range
comparisons are done mostly and bitmasks are useless.  For non-copper
layers, most comparisons are identity comparisons.  I used a simple
pair (m_class and m_index) for a layer identifier.  A pair of
layer identifiers for vias and such .  The index is -1 for back, 0 for
front, and 1 through 2^31-1 for internal layers.  The layer class was
an enumeration (Copper, Dielectric, ...).  A layer pair is a simple
std::pair of layers.  Checking whether a item is on a copper layer is
as simple a comparing its m_class to LayerClass::Copper, just as fast
as a masking operation: faster than int64_t mask on 32-bit archs.
For conversion a const int& constructor for LAYER_ID converted from
the old 32-bit #defines.  An operator int() conversion operator
converted back.  std::set was used to represent an arbitrary set of
layers with operator| operator|= operator& operator&= operator<
 operator>, etc. overloads.  For performance, a small set of often
used methods perform much better than little inline operations in
untold thousands of places.

This was necessary not just to add layers, but to represent concepts
(such as etched resistance layers, 3D keepouts for IDF, hole filling,
plating and finish layers, and many other things) that kicad is
incapable of representing: thus it is incapable of generating proper
GenCAD, GenX, Offspring output for anything but hobby boards.

My old branch from three years ago should still be on launchpad.  Look
in include/class_layer*.h  there is lots of inline documentation.  The
funner stuff was the simulated annealing for location of items in the
vicinity of another.

--brian


-- 
Brian F. G. Bidulock    � The reasonable man adapts himself to the �
bidulock@xxxxxxxxxxx    � world; the unreasonable one persists in  �
http://www.openss7.org/ � trying  to adapt the  world  to himself. �
                        � Therefore  all  progress  depends on the �
                        � unreasonable man. -- George Bernard Shaw �


Follow ups

References