[futurebasic] Re: [FB] re: FutureBasic and Carbon [answers]

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : March 2010 : Group Archive : Group : All Groups

From: PZ <pierrezippi@...>
Date: Tue, 02 Mar 2010 06:20:29 -0600
RE: LLVM and Real Studio

> REAL Software 
> March 1, 2010 9:26 PM
> by Geoff Perlman
> 
> The Compiler: Better, Stronger, Faster
> In the 1970's there was a TV show called the Six Million Dollar Man. It was
> about a test pilot named Steve Austin who crashed in an experimental aircraft
> and lost an eye, an arm and both legs in the crash. When he wakes up in the
> hospital he discovers that he's become an test subject for a government
> experiment to replace body parts with electronic equivalents. But these
> replacement parts are better, stronger and faster than the biological parts
> they have replaced. In fact in the opening of the show, the voice-over says
> that they have made Steve Austin better, stronger and faster.
> 
> Like Steve's legs, the compiler is what makes your apps go. And like Steve, we
> are working on making the compiler better, strong and faster.
> While you don't see REAL Studio's compiler or even interact with it much
> (except when there are errors in your code), it's at the core of REAL Studio.
> It's what turns your REALbasic code into code your computer can execute. The
> compiler has two parts: a front end and a back end. The front end parses your
> code and transforms it into a sort of meta assembly language. Think of this as
> processor-independent assembly (even though regular assembly is actually
> highly processor dependent). For each processor type we support there is a
> different back end to the compiler. The back ends take the meta assembly
> language from the front end and translates it to the assembly for the
> processor for which you are building your app. That means PowerPC or x86
> today.
> 
> We are working on a big change to the back end of our compiler. We are going
> to be replacing it with an open-source compiler back end called LLVM. It's
> becoming increasingly popular. If you really want to geek-out, check out
> LLVM.org. We are moving to LLVM because there is a team of people working on
> LLVM and by switching to it, we get the benefit of their work. For example, it
> supports all the processors we support or would likely want to support
> including the ARM processor which is used by most smartphones including the
> iPhone. Unlike the current REAL Studio compiler, LLVM is an optimizing
> compiler which means it will make code optimizations that will make your code
> run faster. How much faster depends on what your code is doing but we have
> seen speed improvements of up to 10 times faster. LLVM does something called
> "dead-code stripping" which means that it will strip out the portions of the
> REAL Studio framework that your application is not using. This will result in
> smaller applications that use less memory. And for those that deploy on
> Windows and Linux, LLVM will eventually bring about the return of the
> single-file executable. And of course the more improvements that are made to
> LLVM in the future, the more we will benefit.
> 
> Today, we are working on getting LLVM supported for RBScript. That is nearly
> complete. Beta testers have been testing it for several weeks now. Once done,
> we will then move on to supporting LLVM for the main compiler. Considering how
> important the compiler is to REAL Studio, you may be wondering what sort of
> transition will be required to move from a version of REAL Studio that uses
> our current compiler to a future release that uses LLVM. If you were around
> for the last major compiler transition, you are probably especially curious.
> The good news is that because we are changing the back end and not the front
> end, the transition should be extremely smooth. We expect the vast majority of
> you to recompile and only notice that yours apps are smaller and faster. There
> won't be anything new you need to do. That's the beauty of the compiler. It
> does a lot without requiring much attention.
> 
> The move to LLVM is going to be an important step forward for us. And even if
> you don't use RBScript, you will be able to start experimenting with it via
> RBScript in the coming months. Eventually, your applications will get better,
> stronger and faster as well as the REAL Studio IDE since it is created with
> itself.
> 
> 
> REAL Studio LLVM compiling



> From: Brian S <fblistserve@...>
> Reply-To: <futurebasic@...>
> Date: Wed, 24 Feb 2010 12:47:51 -0700
> To: <futurebasic@...>
> Subject: Re: [FB] re: FutureBasic and Carbon [answers]
> 
> 
> On Feb 24, 2010, at 11:54 AM, Robert Purves wrote:
> 
>> 
>> Brian S wrote:
>> 
>>> H. Gluender wrote:
>>> 
>>>> Thanks Pierre for asking and spreading the news...
>>>> 
>>>>> 3. Will the RB Cocoa version compile directly from source to
>>>>> binary or does
>>>>> it generate Objective-C/C code to be passed to gcc/clang?
>>>> 
>>>> Source to binary.
>>>> [...]
>>>> 
>>>>> 8. Does the compiler/linker strip unused code?
>>>> We remove a certain amount of it now but this will happen a lot
>>>> more once we
>>>> swtich to LLVM.
>>>> 
>>>>> 9. Is there a code optimization option as with gcc?
>>>> There are some optimizations now but there will be more with LLVM.
>>>> 
>>>> ------------------------------
>>>> As Brian has noted already this set of replies is puzzling.
>>> 
>>> Pierre - maybe you can ask your RB contact to clarify the apparent
>>> contradictions between #3 compared to #8 & #9 which mention LLVM.
>>> I'm assuming they are defining the RB syntax to LLVM and that is
>>> the plan.
>> 
>> An obvious explanation is that they have another project under way:
>> replacing their direct compiler by a REALbasic frontend for LLVM.
>> This infrastructural detail seems irrelevant to Pierre's choices for
>> porting his programs.
> 
> Agreed on both points and it was my assumption on the first point. The
> most important question RB customer support can answer is WHEN a Cocoa
> version will be ready. Maybe start with an easy question like: Will
> the Cocoa version be available this year? Equivocation on this
> question tends to cast doubt on the IF they will deliver it.
> 
> Pierre, why not test drive the compilers/IDE's you have in mind? The
> list is good for paring down the contenders, but, as with clothes,
> that is the best way to discover if it fits your style, skills and
> technical needs. Moving forward will require a time commitment to
> evaluate & later learn the new development system and its OOP
> implementation.
> 
> 
> 
> 
> 
> 
> --
> To unsubscribe, send ANY message to: futurebasic-unsubscribe@...