On 4/1/07, Petter Urkedal <[EMAIL PROTECTED]> wrote:
On 2007-04-01, Timothy Normand Miller wrote:
> Please go ahead and check this in.  Do we need to discuss where to put
> it and what to name it?

Maybe it's a cryptic name, but I've called it OGA1CP (OGA 1 Central
Processor).  I can rename if you have a better idea.  Then, what I'd
check in is

    rtl/oga1cp/         -- the CPU RTL
    tools/oga1cp/       -- the code gererator API and assembler
    tools/vimfiles/syntax/oga1cp.vim -- highlighting for Vim

> Also, please don't forget to put the full copyright and license notice
> at the top of every file.  Traversal won't be able to use any code
> lacking that in any commercial product.

Are we going to put the whole notice also on Makefiles, READMEs, and
other things, or just on the RTL and other things needed to produce the
hardware?  We could maybe have at least a standard GPL notice for those
supplementary files (as it's much shorter).  As for the software:
    Code generator API (oga1cp.h, oga1cp.c): MIT or the 2-clause BSD?.
    Assembler (oga1cpasm.y): GPL

I think we need to do what is legally necessary for Traversal to do
business.  What that means is that anything that we may relicense,
which may get incorportated into someone else's proprietary released
product, must have the notice, and it should have the full notice so
that no contributor ever misses it and feels deceived.  On the other
hand, Makefiles are tools that don't necessarily become part of
anyone's release and can be easily replaced anyhow.  A lawyer may
disagree with me.  But I think we're taking less of a risk here,
because if someone does complain, we can always replace them.  Plus,
you might also be able to claim that the Makefile is an integral part
of the product, so if the bulk of the product has the license on it,
it would be silly to think something else applied to the tool.

I think, for the short term, we might want to put a comment in
makefiles and readmes that states that the license for these
peripheral tools is the same as the component they belong with.


> wire [31:0] result = (x * y) >> 16;

That could be a good way to approximate floats.  However, it does not
give us shift by variable (REG << REG).

Yes and no.  Shifting left by 5 is multiplying by 32.  But if what you
know is 5 and not 32, then you have a problem.

Anyhow this goes to demonstrate that we cannot predict in advance
everything we need, and we're going to get a lot of it wrong, so we
need to prototype and experiment.

--
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Open Graphics Project
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to