Re: [f-cpu] F-CPU vs ALPHA and licence

[nicO <nicolas.boulay@ifrance.com>]

Yann Guidon a écrit :
> 
> hi !
> 
> (with this flood of emails, i wasn't able to compile anything today,
> not even MR's preprocessors... so don't worry if i stay mute awhile :-D)
> 
> nicO wrote:
> > Yann Guidon a écrit :
> > > nicO wrote:
> > > > >Use semaphores that are mapped in the SRs !
> > > > In all case, we need to write something in memory or to touch something
> > > > in the VM unit.
> > > why ? a semaphore is a semaphore, a flag if you want.
> > > whether it is implemented in memory or with a dedicated HW in
> > > a different addressign space, is "implementation dependent".
> >
> > In all case, you have one memory access + 1 or more port to the outside.
> maybe not. I am thinking about a separate and dedicated port in the chip,
> that will communicate to a central FPGA or ASIC that will perform the
> arbitration. a dozen of signal pins do the trick.
> 

Yep, it's 12 pins more for a very short use. We add the chipset inside
the fcpu to avoid an other chip and you want to introduice another chip
! This chip to be fast will need as many port as cpu. In all case, this
component must be design. In actual chip design, we don't make
difference with system boad and the cpu chip. So if we could put this
componant inside the fcpu we will gain a lot of money ! Soc
(system-on-chip) are not just fashon. It's how todays chip are made.
Nowdays, you would never see an ARM in a chip alone, NEVER. StrongARM
are _the_ only exception. 

Before, you will choose between chips to make your system. Nowdays, if
you want to make more than 100 000 pieces you will choose the good IP
and then make your system. Most of it on the same die for cost and power
saving problem (less pin, so less power transistor, ...). 

So my problem concern our licence, the GPL. We say it's ok ! Because we
couldn't mix GPL code and private code, but we could mix after at the
layout level. The problem is that isn't very usefull for a compagny to
do it at this level. LEON was written in LGPL to be used with the meiko
floating point unit, very easly. 

In your case, to make a Chip (or a SOC, it the same !), all vhdl code
must be in GPL. All the code ! Which compagny would make a fcpu if it
couldn't add something to create more value than the other ? That said
that we will never use all proprietary interface (IEEE1394, ethernet,
USB, PCI, hyperband,...) so nobody could be connected to a fcpu at low
cost. Never forget that board=chip, todays.

If the code stay in GPL, it will be very difficult for compagny not to
release all it's code in GPL. I personnaly think it's too much to ask.
We made a cpu not systems. A computer could be used in very different
way what is in common with a numerical camera, an hard disk controleur,
or a PDA. In each of this system, you could use a fcpu BUT, peripherals
and interface could be very different (no need of LCD display port for
the hard disk controleur).

In SW, Linux and some software are in GPL but could be used with
proprietary program. Lot of compagny want to sell solution with linux
for embedded market, for example. This system work well, no code stolen,
but you could sell something, so made a wide spread of the GPL code (Red
hat, Mandrake are responsible to make linux so well known, never forget
that !).

 In the case of the fcpu, where a compagny could make money ? By selling
exactly the same chip than the other ? But no system is built like that,
any more (no use in SoC)! So forget the use of the fcpu in wide spread
use.

It's still possible to change our licence because few people write
code(whygee and Michael, that's all i think). I think that LGPL are more
appropriate.

> > Plus, you could add many problem for multicpu system. So there isn't any
> > port dedicated to it, and shouldn't have ! Because it so tight to the
> > OS, that we could have many compatibility problem in the futur.
> if the SR interface is respected, it is transparent to the OS.
> 
> > I think
> > you thought to an implementation of SGI not really usual processor.
> SGI Indigo and other similar machines have a central semaphore management
> that does not pollute the memory system.
> 
> > Today's µp implement semaphore with atomic read_modify_write
> > instructions.
> so what ?

So you don't need special port !

> 
> > > > So it's just pushing the problem away !
> > > and if possible where it doesn't disturb us :-P
> > >
> > > the L/S unit is optimised to allow high bandwidth through
> > > cache-line width packet transfers, accessing single bytes
> > > in scattered order is a good way to "kill" your memory subsystem
> > > and the speed of your synchronisation.
> >
> > You could add specific memory barrer (semaphore aren't so common!).
> there is already a "barrier" ("serialize").
> the problem is that not only it stalls the pipeline, but it
> also perturbates the memory system's behaviour. It is used only
> in "critical" sections that deal with DMA or I/O for example
> ("low speed" things). OTOH you would want your semaphore to be
> effective in as few cycles as possible. when doing fine grained
> multitasking and multiprocessing, the semaphore latency can become
> the killer, especially in real-time.
> 
> > > > More generaly, i find the text very agressive against Alpha.(the 2 first
> > > > sentences of the text, for example). We should never forget that alpha
> > > > work since 10 years and fcpu is in it's very beginning. So this kink of
> > > > speech could make laught a futur investor in the fcpu, never forget
> > > > that.
> > >
> > > i think that you know that i am not "agressive" and that i respect the
> > > ALPHA. I have two expensive books about it and unfortunately no
> > > Alpha server at home.
> > >
> > > We can still discuss whether Alpha is dead or not. CPQ will keep
> > > Alpha alive artificially as long as IA64 is not a serious competitor.
> > > that is enough for me : it's just marketing and financial manipulation,
> > > the ALPHA engineers have a very reduced freedom of decision now,
> > > because they know that it will be dropped after the 364.
> > >
> > > So i could say : Alpha is dead as much as F-CPU is alive.
> > > it's time to learn alpha's lessons, i think.
> > >
> >
> > the problem is the tone not the content.
> 
> what would you write instead ?

Avoid bads word.

nicO
> 
> > nicO
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> *************************************************************
> To unsubscribe, send an e-mail to majordomo@seul.org with
> unsubscribe f-cpu       in the body. http://f-cpu.seul.org/
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/