Re: C++ in the kernel

Poul-Henning Kamp wrote:
> One major problem I see about a C++ runtime, is that it puts even
> worse constraints on our compiler situation, raising the bar
> significantly for any non GPLv3 compiler we might consider.
>   

I agree with this point. I am certainly not suggesting that we become 
more, not less, tightly coupled to a particular vendor's compiler.  I 
believe Stroustrup would also agree on the first -- it must have occured 
to him how to save people from reinventing the runtime support wheel 
every time a new compiler comes out.

I agree with your other point regarding the isolation K seems to offer 
in this respect. Re your last point, scanning the feeds it sounds like 
Linux are having problems with GCC code generation too right now.

Anyway, I hope people do not form the opinion from this thread that 
there is an Operation Impending C++ Doom up my sleeve -- there ain't -- 
however I do feel the need to give people a whiff of the C++ coffee. It 
is an advanced tool which has a high learning curve; it does have a 
place in kernels and embedded systems; it's an industry fact of life; 
like anything in life, it has its good and its bad.

Thanks for informed debate!
BMS
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"

Re: C++ in the kernel

In message <20071102203803.GO77844 <at> elvis.mu.org>, Alfred Perlstein writes:

>A policy that might be interesting is to do something along
>the lines of what we do with GPL, basically, core code in the
>kernel can not be based on nor depend on it.

I don't know if this is realistically possible, without some
kind of intermediate layer to translate, for instance inline
assembly.

But apart from it being a lot of, currently, pointless work that
would really gain us anything, as long as no viable competitors to
GCC exists, I fully agree:  Either you take portability seriously
(ie: run with any compiler) or you handle portability seriously
(ie: run it through our frontend, so any compiler can cope).

But in any case, this is all very theoretical until there are
a non-comical alternative compiler for us.

--

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk <at> FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"

Re: C++ in the kernel

* Bruce M Simpson <bms <at> incunabulum.net> [071102 12:43] wrote:
> Poul-Henning Kamp wrote:
> >One major problem I see about a C++ runtime, is that it puts even
> >worse constraints on our compiler situation, raising the bar
> >significantly for any non GPLv3 compiler we might consider.
> >  
> 
> I agree with this point. I am certainly not suggesting that we become 
> more, not less, tightly coupled to a particular vendor's compiler.  I 
> believe Stroustrup would also agree on the first -- it must have occured 
> to him how to save people from reinventing the runtime support wheel 
> every time a new compiler comes out.
> 
> I agree with your other point regarding the isolation K seems to offer 
> in this respect. Re your last point, scanning the feeds it sounds like 
> Linux are having problems with GCC code generation too right now.
> 
> Anyway, I hope people do not form the opinion from this thread that 
> there is an Operation Impending C++ Doom up my sleeve -- there ain't -- 
> however I do feel the need to give people a whiff of the C++ coffee. It 
> is an advanced tool which has a high learning curve; it does have a 
> place in kernels and embedded systems; it's an industry fact of life; 
> like anything in life, it has its good and its bad.
> 
> Thanks for informed debate!
> BMS

A policy that might be interesting is to do something along
the lines of what we do with GPL, basically, core code in the
kernel can not be based on nor depend on it.  We could say the

Re: C++ in the kernel

* Poul-Henning Kamp <phk <at> phk.freebsd.dk> [071102 13:53] wrote:
> In message <20071102203803.GO77844 <at> elvis.mu.org>, Alfred Perlstein writes:
> 
> >A policy that might be interesting is to do something along
> >the lines of what we do with GPL, basically, core code in the
> >kernel can not be based on nor depend on it.
> 
> I don't know if this is realistically possible, without some
> kind of intermediate layer to translate, for instance inline
> assembly.
> 
> But apart from it being a lot of, currently, pointless work that
> would really gain us anything, as long as no viable competitors to
> GCC exists, I fully agree:  Either you take portability seriously
> (ie: run with any compiler) or you handle portability seriously
> (ie: run it through our frontend, so any compiler can cope).
> 
> But in any case, this is all very theoretical until there are
> a non-comical alternative compiler for us.

I really don't understand what you're saying here.

All I'm saying is that if we choose to "support" C++ (or any other
language), we can come to a compromise where core code does not
depend on it, at least for some timeframe so as to ease people's
fears.

I would honestly hate to see anything added and within a week or a
month there are key systems that _used to work just fine_ retrofitted
to depend on said compiler/tool/preprocessor/whatever.

Request a Free Catalog and receive $10 off your first purchase

Request a free catalog and receive $10 your first purchase

http://www.tackwholesale.com/Catalog_Request_Special02.htm

put this link in your browser

Click here on
http://server1.streamsend.com/streamsend/unsubscribe.php?cd=34302&md=192&ud=0fa55a21584f2ce925f2533f7d3de2c8
<http://server1.streamsend.com/streamsend/unsubscribe.php?cd=34302&md=192&ud=0fa55a21584f2ce925f2533f7d3de2c8>
to update your profile or Unsubscribe
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"

Objective-C kernel Development

Has Objective-C ever been concidered for kernel development?

regards,
BPC

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

Re: Objective-C kernel Development

More interesting choices are java or C# just because they are typesafe (e.g.:
JX, singularity). I'm not sure why anyone would want to suffer with obj-c?

Ali

On 11/5/07, Ben Crowhurst <Ben.Crowhurst <at> travel2.com> wrote:
>
> Has Objective-C ever been concidered for kernel development?
>
> regards,
> BPC
>
> _______________________________________________
> freebsd-arch <at> freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
>

--

-- 
Ali Mashtizadeh
علی مشتی زاده

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

Re: Objective-C kernel Development

Ali Mashtizadeh wrote:
> More interesting choices are java or C# just because they are typesafe (e.g.:
> JX, singularity). I'm not sure why anyone would want to suffer with obj-c?

When we're at it, why not Python? :)

(I'd like to color it green...)

Re: Objective-C kernel Development

> Ali Mashtizadeh wrote:
> > More interesting choices are java or C# just because they are typesafe (e.g.:
> > JX, singularity). I'm not sure why anyone would want to suffer with obj -c?
> 
> When we're at it, why not Python? :)
> 
> 
> (I'd like to color it green...)

That is not changing the bikeshed color; that is changing the
bikeshed with a parking lot.
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"

Re: Objective-C kernel Development

* Ivan Voras <ivoras <at> freebsd.org> [071105 14:11] wrote:
> Ali Mashtizadeh wrote:
> > More interesting choices are java or C# just because they are typesafe (e.g.:
> > JX, singularity). I'm not sure why anyone would want to suffer with obj-c?
> 
> When we're at it, why not Python? :)
> 
> 
> 
> (I'd like to color it green...)
> 

I think the gist of it is that the FreeBSD project will certainly
consider bringing in runtime environments for just about anything,
however entertaining the idea of it becoming an "official" extention
and replacing or bringing in core-code that requires said runtime
or language will most likely not be allowed until the tool is
allowed to settle for some number of years.

--

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