Jean-Marc Lienher | 1 Jul 2006 02:26

Alternative compiler toolchain ?

Hi all,

I'm new to FreeBSD, I was using Linux since 1997.
But I decided to switch to the Daemon and leave the Penguin on
his Iceberg.
(Yes, for those who are reading the hidden e-mail headers,
I'm also using MS-Windows :-)

After a (too?) quick look at the FreeBSD source code, I've seen that
the GNU compiler toolchain was used to compile the kernel and other
part of the OS.

I would like to know if there is another compiler toolchain
(C compiler, assembler and linker) which is able to build the i386
FreeBSD and which is released under the BSD, MIT or any other
non-viral license ?

I've found some other compilers on the web:
http://fabrice.bellard.free.fr/tcc/  (LGPL)
http://www.cs.princeton.edu/software/lcc/ (Free for personal use)
http://tack.sourceforge.net/ (BSD)

The last one, ACK (the Minix compiler), is released under a
good license. Does somebody have ever tried to compile FreeBSD
with it ?

Thanks,
 Jean-Marc Lienher

 +---------------------------------+                                 +
(Continue reading)

Kip Macy | 1 Jul 2006 03:16
Picon

Re: NVIDIA FreeBSD kernel feature requests

WOW THATS GREAT DOUG! \0/ - it didn't work for me.
 -Kip

On 6/30/06, Doug Ambrisko <ambrisko <at> ambrisko.com> wrote:
> Kip Macy writes:
> | IIRC lack of per instance cdevs also limits Freebsd to one vmware instance.
>
> Really?  Don't tell my vmware multiple instances!  I used to run 10 on
> one FreeBSD host.
>
> Doug A.
>
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Steve Kargl | 1 Jul 2006 03:57
Picon

Re: Alternative compiler toolchain ?

On Sat, Jul 01, 2006 at 02:26:35AM +0200, Jean-Marc Lienher wrote:
> 
> After a (too?) quick look at the FreeBSD source code, I've seen that
> the GNU compiler toolchain was used to compile the kernel and other
> part of the OS.
> 
> I would like to know if there is another compiler toolchain
> (C compiler, assembler and linker) which is able to build the i386
> FreeBSD and which is released under the BSD, MIT or any other
> non-viral license ?

The only thing that might come close to your criteria
is ten15.

--

-- 
Steve
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Alastair G. Hogge | 1 Jul 2006 03:46
Picon
Favicon

Re: Alternative compiler toolchain ?

On Saturday 01 July 2006 10:26, Jean-Marc Lienher wrote:
> Hi all,
G'Day,

> I'm new to FreeBSD, I was using Linux since 1997.
> But I decided to switch to the Daemon and leave the Penguin on
> his Iceberg.
> (Yes, for those who are reading the hidden e-mail headers,
> I'm also using MS-Windows :-)
Welcome aboard then.
(Yes, for those who are reading the hidden e-mail headers,
I'm also using Krappy^H^H^H^H^H
Kmail :-)

> After a (too?) quick look at the FreeBSD source code, I've seen that
> the GNU compiler toolchain was used to compile the kernel and other
> part of the OS.
As I understand it, GCC provided very good optimization code for an 
open-source project plus it is supported a $% <at>  load of platforms.

> I would like to know if there is another compiler toolchain
> (C compiler, assembler and linker) which is able to build the i386
> FreeBSD and which is released under the BSD, MIT or any other
> non-viral license ?
Well there's TenDRA[1]. I think someone was once working on getting it to 
build the base system.....

[1]ten15.org or tendra.org. They are both forks of the original TenDRA 
project. Chatting to some friendlies in #TenDRA[2] on freenode suggests that 
there work is still to young to even build ELF binaries on FreeBSD. So it 
(Continue reading)

Doug Ambrisko | 1 Jul 2006 04:16

Re: NVIDIA FreeBSD kernel feature requests

Kip Macy writes:
| WOW THATS GREAT DOUG! \0/ - it didn't work for me.

This was with the last patched driver for vmware 2.  I'm not sure if
it every made it into the port. 

http://www.mindspring.com/~vsilyaev/vmware/files/changes
  28 Jan 01 Version 0.99-1-0.22
        Support for multiple vmware sessions
                                Thnx to  Luigi Rizzo
        Support for bridged and host-only networking
        Some fixes for -STABLE and -CURRENT

Looking at the port I don't see that it's been update to 99 yet.

Doug A.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Dan Nelson | 1 Jul 2006 05:21
Gravatar

Re: Alternative compiler toolchain ?

In the last episode (Jul 01), Jean-Marc Lienher said:
> After a (too?) quick look at the FreeBSD source code, I've seen that
> the GNU compiler toolchain was used to compile the kernel and other
> part of the OS.
> 
> I would like to know if there is another compiler toolchain (C
> compiler, assembler and linker) which is able to build the i386
> FreeBSD and which is released under the BSD, MIT or any other
> non-viral license ?

Luckily gcc's license doesn't apply to the executables it generates :)

> I've found some other compilers on the web:
> http://fabrice.bellard.free.fr/tcc/  (LGPL)

tcc is very fast, probably has the most modern C parser of the lot, and
might even be able to build world except that the shared binaries it
generates aren't able to be loaded by our rtld.  It looks like tcc only
emits the bare minimum to get Linux to run the executable, and I don't
know enough about the ELF format to fill in the blanks.

> http://www.cs.princeton.edu/software/lcc/ (Free for personal use)
> http://tack.sourceforge.net/ (BSD)
> 
> The last one, ACK (the Minix compiler), is released under a
> good license. Does somebody have ever tried to compile FreeBSD
> with it ?

ACK can't generate executables for any modern system except Solaris, so
it would have to have a lot of work done on it to be useful.
(Continue reading)

Kamal R. Prasad | 1 Jul 2006 07:14
Picon
Favicon

Re: freebsd port onto IBM/Lenovo T 40

The link points to a commercial s/w. Is there interest in getting a free
driver for this? Any T40 sensor enabled laptop users run freebsd?

thanks
-kamal

On 6/30/06, Julian Elischer <julian <at> elischer.org> wrote:
>
> Anish Mistry wrote:
>
> >On Friday 30 June 2006 04:49, Kamal R. Prasad wrote:
> >
> >
> >>Hello,
> >>
> >>
> >>
> [...]
>
> >http://shapeshifter.se/articles/upek_touchchip_freebsd/
> >
> >
> >
> I'm impressed
>
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

(Continue reading)

Divacky Roman | 1 Jul 2006 10:05
Picon
Favicon

Re: Alternative compiler toolchain ?

On Fri, Jun 30, 2006 at 10:21:39PM -0500, Dan Nelson wrote:
> In the last episode (Jul 01), Jean-Marc Lienher said:
> > After a (too?) quick look at the FreeBSD source code, I've seen that
> > the GNU compiler toolchain was used to compile the kernel and other
> > part of the OS.
> > 
> > I would like to know if there is another compiler toolchain (C
> > compiler, assembler and linker) which is able to build the i386
> > FreeBSD and which is released under the BSD, MIT or any other
> > non-viral license ?
> 
> Luckily gcc's license doesn't apply to the executables it generates :)
>  
> > I've found some other compilers on the web:
> > http://fabrice.bellard.free.fr/tcc/  (LGPL)
> 
> tcc is very fast, probably has the most modern C parser of the lot, and
> might even be able to build world except that the shared binaries it
> generates aren't able to be loaded by our rtld.  It looks like tcc only
> emits the bare minimum to get Linux to run the executable, and I don't
> know enough about the ELF format to fill in the blanks.

afaik tendra doesnt support gnu C extensions and our srcs are full of it
so the only possible compilers ATM are gcc and icc
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

(Continue reading)

Hans Petter Selasky | 1 Jul 2006 10:44

Re: contiguous memory allocation problem

On Friday 30 June 2006 22:32, Peter Jeremy wrote:
> On Fri, 2006-Jun-30 20:29:28 +0200, Hans Petter Selasky wrote:
> >I sometimes see that the USB driver is unable to allocate contiguous
> > memory for itself. For example I noticed that FreeBSD was unable to
> > allocate 350kbytes of contiguous memory after that I had run "konqueror",
> > the KDE web browser and various other memory consuming applications for a
> > while.
>
> I reported this about 18 months ago and I'm fairly certain you even
> contributed to the thread at the time.
>
> >Any comments?
>
> The latest concensus seems to be that the USB system should make use of
> the scatter-gather facilities in the hardware to avoid the need to
> allocate large contiguous memory chunks.  iedowse <at>  had mostly finished
> implementing this in mid May.

Yes, but scatter and gather will add extra complexity to the driver, and maybe 
an extra memory copy in most cases. The idea is to allocate less than or 
equal to a page of memory, and then avoid the problem?

The most important thing is to keep memory allocations of constant size. For 
example under my USB system, all memory is allocated at attach. There is no 
longer allocation and freeing of memory during usage, with a few exceptions. 
I was thinking I could pre-allocate 2-4MB for the USB system, then make a 
list of freed memory blocks, and then search this list first, before 
allocating new memory.

Depending on how many different kinds of equipment one plugs, this should work 
(Continue reading)

Matthias Andree | 1 Jul 2006 10:35
Picon
Picon

Re: Return value of malloc(0)

Pat Lashley <patl+freebsd <at> volant.org> writes:

> BUT, that said, the safest and most portable coding practice would be:
>
>        // The C standard does not require malloc(0) to return NULL;
>        // but whatever it returns MUST NOT be dereferenced.
>        ptr = ( size == 0 ) ? NULL : malloc( size ) ;

Safest (avoiding null derefence) would instead be:

       ptr = malloc(size ? size : 1);

BTW: // is not a valid C89 comment, but a GCC-ism.

--

-- 
Matthias Andree
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"


Gmane