ARM Announces RVCT 3.0 for Brew! | developer.brewmp.com ARM Announces RVCT 3.0 for Brew! | developer.brewmp.com

Developer

ARM Announces RVCT 3.0 for Brew!

Has anyone used the RVCT 3.0 before? ARM just announced they are selling RVCT 3.0 for Brew separate from their main SDK for $1500: http://www.arm.com/news/17813.html

Can anyone please comment on whether you'd still have to use the Brew-specific workaround to access the vtable (see below) or whether we can code standard C++ once we get back an interface from IShell_CreateInstance()?

I am referring to the following Vtable workaround:

#define IXMODE_Disconnect(p)\
(*((IXmodeVtbl**)p))->Disconnect(p)

struct IXmodeVtbl
{
TXmodeResult (*Disconnect) (IXmode*);

Any ideas?

Thank you,
Gili

cowwoc wrote:Has anyone used the RVCT 3.0 before? ARM just announced they are selling RVCT 3.0 for Brew separate from their main SDK for $1500: http://www.arm.com/news/17813.html
Can anyone please comment on whether you'd still have to use the Brew-specific workaround to access the vtable (see below) or whether we can code standard C++ once we get back an interface from IShell_CreateInstance()?
The RVCT 3.0 uses the C++ ABI (Application Binary Interface) which has a vtable layout matching that of the COM-style BREW interfaces. RVCT 1.2 used the ADSABI, which has the problems you note. However, since several BREW APIs use variadic macros, if you want to use these you will need to compile your code using the ADSABI. This will be the default option in the compiler - you will need to explicitly enable the C++ ABI.
Airsource evaluated the new toolchain for ARM, and we'll be discussing the performance improvements in our talk at BREW 2007, Friday 1:45pm.

cowwoc wrote:Has anyone used the RVCT 3.0 before? ARM just announced they are selling RVCT 3.0 for Brew separate from their main SDK for $1500: http://www.arm.com/news/17813.html
Can anyone please comment on whether you'd still have to use the Brew-specific workaround to access the vtable (see below) or whether we can code standard C++ once we get back an interface from IShell_CreateInstance()?
The RVCT 3.0 uses the C++ ABI (Application Binary Interface) which has a vtable layout matching that of the COM-style BREW interfaces. RVCT 1.2 used the ADSABI, which has the problems you note. However, since several BREW APIs use variadic macros, if you want to use these you will need to compile your code using the ADSABI. This will be the default option in the compiler - you will need to explicitly enable the C++ ABI.
Airsource evaluated the new toolchain for ARM, and we'll be discussing the performance improvements in our talk at BREW 2007, Friday 1:45pm.

BenBlaukopf wrote:The RVCT 3.0 uses the C++ ABI (Application Binary Interface) which has a vtable layout matching that of the COM-style BREW interfaces. RVCT 1.2 used the ADSABI, which has the problems you note. However, since several BREW APIs use variadic macros, if you want to use these you will need to compile your code using the ADSABI. This will be the default option in the compiler - you will need to explicitly enable the C++ ABI.
Airsource evaluated the new toolchain for ARM, and we'll be discussing the performance improvements in our talk at BREW 2007, Friday 1:45pm.
What happens if a customer wishes to use my library which was compiled using C++ ABI while also using the existing BREW APIs that use variadic macros? How can he do both?
Is C++ ABI available in the free gnu compilers or is this specific to the ARM compiler?
The compiler claims to support the ISO C++ standard, does that mean that we can use exception handling (standard built-in types and user-defined exceptions) to our heart's content? The same question about templates.
I've been reading discussions on forums and most people seem to be advocating the use of WinARM, though from what I read this isn't C++ ABI compliant. Is there a free compiler that is C++ ABI compliant or does this only work with ARM's RVCT?
Thank you,
Gili

BenBlaukopf wrote:The RVCT 3.0 uses the C++ ABI (Application Binary Interface) which has a vtable layout matching that of the COM-style BREW interfaces. RVCT 1.2 used the ADSABI, which has the problems you note. However, since several BREW APIs use variadic macros, if you want to use these you will need to compile your code using the ADSABI. This will be the default option in the compiler - you will need to explicitly enable the C++ ABI.
Airsource evaluated the new toolchain for ARM, and we'll be discussing the performance improvements in our talk at BREW 2007, Friday 1:45pm.
What happens if a customer wishes to use my library which was compiled using C++ ABI while also using the existing BREW APIs that use variadic macros? How can he do both?
Is C++ ABI available in the free gnu compilers or is this specific to the ARM compiler?
The compiler claims to support the ISO C++ standard, does that mean that we can use exception handling (standard built-in types and user-defined exceptions) to our heart's content? The same question about templates.
I've been reading discussions on forums and most people seem to be advocating the use of WinARM, though from what I read this isn't C++ ABI compliant. Is there a free compiler that is C++ ABI compliant or does this only work with ARM's RVCT?
Thank you,
Gili

cowwoc wrote:What happens if a customer wishes to use my library which was compiled using C++ ABI while also using the existing BREW APIs that use variadic macros? How can he do both?
With difficulty. I haven't tested out an approach to this yet, but I'll be looking at it.
Quote:
Is C++ ABI available in the free gnu compilers or is this specific to the ARM compiler?
The compiler claims to support the ISO C++ standard, does that mean that we can use exception handling (standard built-in types and user-defined exceptions) to our heart's content? The same question about templates.
I've been reading discussions on forums and most people seem to be advocating the use of WinARM, though from what I read this isn't C++ ABI compliant. Is there a free compiler that is C++ ABI compliant or does this only work with ARM's RVCT?
I thought WinARM was C++ ABI compliant - it's ADS that isn't. Exceptions and templates are both supported, though exceptions are disabled out of the box, you need to enable them.

cowwoc wrote:What happens if a customer wishes to use my library which was compiled using C++ ABI while also using the existing BREW APIs that use variadic macros? How can he do both?
With difficulty. I haven't tested out an approach to this yet, but I'll be looking at it.
Quote:
Is C++ ABI available in the free gnu compilers or is this specific to the ARM compiler?
The compiler claims to support the ISO C++ standard, does that mean that we can use exception handling (standard built-in types and user-defined exceptions) to our heart's content? The same question about templates.
I've been reading discussions on forums and most people seem to be advocating the use of WinARM, though from what I read this isn't C++ ABI compliant. Is there a free compiler that is C++ ABI compliant or does this only work with ARM's RVCT?
I thought WinARM was C++ ABI compliant - it's ADS that isn't. Exceptions and templates are both supported, though exceptions are disabled out of the box, you need to enable them.

BenBlaukopf wrote:With difficulty. I haven't tested out an approach to this yet, but I'll be looking at it.
Please let me know what you find out as I will need to use this.
I thought WinARM was C++ ABI compliant - it's ADS that isn't. Exceptions and templates are both supported, though exceptions are disabled out of the box, you need to enable them.
Why are exceptions disabled out of the box? Where can I read more about WinARM? I am finding it very short on documentation. Where are the limitations of WinARM documented? Can I use full-fledged ISO C++ on it or does it have some limitations? I remember reading that older Brew toolchains disallowed virtual methods, etc.
Thank you,
Gili

BenBlaukopf wrote:With difficulty. I haven't tested out an approach to this yet, but I'll be looking at it.
Please let me know what you find out as I will need to use this.
I thought WinARM was C++ ABI compliant - it's ADS that isn't. Exceptions and templates are both supported, though exceptions are disabled out of the box, you need to enable them.
Why are exceptions disabled out of the box? Where can I read more about WinARM? I am finding it very short on documentation. Where are the limitations of WinARM documented? Can I use full-fledged ISO C++ on it or does it have some limitations? I remember reading that older Brew toolchains disallowed virtual methods, etc.
Thank you,
Gili

BenBlaukopf wrote:The RVCT 3.0 uses the C++ ABI (Application Binary Interface) which has a vtable layout matching that of the COM-style BREW interfaces. RVCT 1.2 used the ADSABI, which has the problems you note. However, since several BREW APIs use variadic macros, if you want to use these you will need to compile your code using the ADSABI. This will be the default option in the compiler - you will need to explicitly enable the C++ ABI.
Airsource evaluated the new toolchain for ARM, and we'll be discussing the performance improvements in our talk at BREW 2007, Friday 1:45pm.
Will you discuss the use of templates and exceptions and gotchas/restrictions?
Thanks...

BenBlaukopf wrote:The RVCT 3.0 uses the C++ ABI (Application Binary Interface) which has a vtable layout matching that of the COM-style BREW interfaces. RVCT 1.2 used the ADSABI, which has the problems you note. However, since several BREW APIs use variadic macros, if you want to use these you will need to compile your code using the ADSABI. This will be the default option in the compiler - you will need to explicitly enable the C++ ABI.
Airsource evaluated the new toolchain for ARM, and we'll be discussing the performance improvements in our talk at BREW 2007, Friday 1:45pm.
Will you discuss the use of templates and exceptions and gotchas/restrictions?
Thanks...

brewisv wrote:Will you discuss the use of templates and exceptions and gotchas/restrictions?
Thanks...
Riffware have used templates more extensively than us, and you might want to have a chat with them - there are three of their guys at the conference. Neither of us have used exceptions much - I simply did a quick test to see if they worked and nothing more extensive, as our evaluation was directed at our existing code base. In addition, exceptions aren't usually that valuable for embedded code.

brewisv wrote:Will you discuss the use of templates and exceptions and gotchas/restrictions?
Thanks...
Riffware have used templates more extensively than us, and you might want to have a chat with them - there are three of their guys at the conference. Neither of us have used exceptions much - I simply did a quick test to see if they worked and nothing more extensive, as our evaluation was directed at our existing code base. In addition, exceptions aren't usually that valuable for embedded code.

BenBlaukopf wrote:Riffware have used templates more extensively than us, and you might want to have a chat with them - there are three of their guys at the conference. Neither of us have used exceptions much - I simply did a quick test to see if they worked and nothing more extensive, as our evaluation was directed at our existing code base. In addition, exceptions aren't usually that valuable for embedded code.
Hi Ben,
Unfortunately I'm not attending the conference so I can't ask the Riffware guys directly. Should I just fire off an email off their website or can you casually point them in the direction of this post to reply? :)
You said you got exceptions working, are there any instructions on getting that up and running? I couldn't find any (including on your site).
Thanks,
Gili

BenBlaukopf wrote:Riffware have used templates more extensively than us, and you might want to have a chat with them - there are three of their guys at the conference. Neither of us have used exceptions much - I simply did a quick test to see if they worked and nothing more extensive, as our evaluation was directed at our existing code base. In addition, exceptions aren't usually that valuable for embedded code.
Hi Ben,
Unfortunately I'm not attending the conference so I can't ask the Riffware guys directly. Should I just fire off an email off their website or can you casually point them in the direction of this post to reply? :)
You said you got exceptions working, are there any instructions on getting that up and running? I couldn't find any (including on your site).
Thanks,
Gili

Hi Gili,
I'll ask the Riffware guys to take a look at this thread. Regarding exceptions, I don't have RVCT installed on my laptop, so can't check this, but getting exceptions going was very simple - something like -fexceptions.

Hi Gili,
I'll ask the Riffware guys to take a look at this thread. Regarding exceptions, I don't have RVCT installed on my laptop, so can't check this, but getting exceptions going was very simple - something like -fexceptions.

cowwoc wrote:Has anyone used the RVCT 3.0 before? ARM just announced they are selling RVCT 3.0 for Brew separate from their main SDK for $1500: http://www.arm.com/news/17813.html
It looks like they have changed the business model. Instead of $1500 for ADS1.2 without time limitation, the new RVCT 3.0 for BREW is actually $1500 per seat (node locked, as before) PER YEAR. This means that if we keep RVCT 3.0 for BREW for a few years it could be far more expensive than the RVCT 3.0 standard version, which is $6000.
Of course the upgrade from ARM Builder 1.2 to RVCT 3.0 ain't cheap either.

cowwoc wrote:Has anyone used the RVCT 3.0 before? ARM just announced they are selling RVCT 3.0 for Brew separate from their main SDK for $1500: http://www.arm.com/news/17813.html
It looks like they have changed the business model. Instead of $1500 for ADS1.2 without time limitation, the new RVCT 3.0 for BREW is actually $1500 per seat (node locked, as before) PER YEAR. This means that if we keep RVCT 3.0 for BREW for a few years it could be far more expensive than the RVCT 3.0 standard version, which is $6000.
Of course the upgrade from ARM Builder 1.2 to RVCT 3.0 ain't cheap either.

scheng_nz wrote:It looks like they have changed the business model. Instead of $1500 for ADS1.2 without time limitation, the new RVCT 3.0 for BREW is actually $1500 per seat (node locked, as before) PER YEAR. This means that if we keep RVCT 3.0 for BREW for a few years it could be far more expensive than the RVCT 3.0 standard version, which is $6000.
Of course the upgrade from ARM Builder 1.2 to RVCT 3.0 ain't cheap either.
I was scratching my head on that "one year term" clause too. It's time to investigate WinARM seriously.

scheng_nz wrote:It looks like they have changed the business model. Instead of $1500 for ADS1.2 without time limitation, the new RVCT 3.0 for BREW is actually $1500 per seat (node locked, as before) PER YEAR. This means that if we keep RVCT 3.0 for BREW for a few years it could be far more expensive than the RVCT 3.0 standard version, which is $6000.
Of course the upgrade from ARM Builder 1.2 to RVCT 3.0 ain't cheap either.
I was scratching my head on that "one year term" clause too. It's time to investigate WinARM seriously.

We have been using RVDS 3.0 (the full version) for the last year. We don't use exceptions, but we are very heavy in our template use. So far we have not found anything that is not supported.
In our experience RVDS 3, or the new RVCT 3, is VERY solid and extremely beneficial. The Edison Design Group front end is first class and really ensures that your C++ will be compiled correctly.
The yearly fee is definitely a cause for frustration. However, $1500/yr or $6k flat is well worth it when you consider the time spent getting something else to work and then finding some random bug right before you plan to ship.
Time is money, and nothing can kill you like a tool chain bug.

We have been using RVDS 3.0 (the full version) for the last year. We don't use exceptions, but we are very heavy in our template use. So far we have not found anything that is not supported.
In our experience RVDS 3, or the new RVCT 3, is VERY solid and extremely beneficial. The Edison Design Group front end is first class and really ensures that your C++ will be compiled correctly.
The yearly fee is definitely a cause for frustration. However, $1500/yr or $6k flat is well worth it when you consider the time spent getting something else to work and then finding some random bug right before you plan to ship.
Time is money, and nothing can kill you like a tool chain bug.

ZeroCool wrote:We have been using RVDS 3.0 (the full version) for the last year. We don't use exceptions, but we are very heavy in our template use. So far we have not found anything that is not supported.
In our experience RVDS 3, or the new RVCT 3, is VERY solid and extremely beneficial. The Edison Design Group front end is first class and really ensures that your C++ will be compiled correctly.
The yearly fee is definitely a cause for frustration. However, $1500/yr or $6k flat is well worth it when you consider the time spent getting something else to work and then finding some random bug right before you plan to ship.
Time is money, and nothing can kill you like a tool chain bug.
It's also worth noting that RVCT 3.0 produces code that is 20-30% faster than GCC - which is a pretty good improvement!

ZeroCool wrote:We have been using RVDS 3.0 (the full version) for the last year. We don't use exceptions, but we are very heavy in our template use. So far we have not found anything that is not supported.
In our experience RVDS 3, or the new RVCT 3, is VERY solid and extremely beneficial. The Edison Design Group front end is first class and really ensures that your C++ will be compiled correctly.
The yearly fee is definitely a cause for frustration. However, $1500/yr or $6k flat is well worth it when you consider the time spent getting something else to work and then finding some random bug right before you plan to ship.
Time is money, and nothing can kill you like a tool chain bug.
It's also worth noting that RVCT 3.0 produces code that is 20-30% faster than GCC - which is a pretty good improvement!

cowwoc wrote:Why are exceptions disabled out of the box? Where can I read more about WinARM? I am finding it very short on documentation. Where are the limitations of WinARM documented? Can I use full-fledged ISO C++ on it or does it have some limitations? I remember reading that older Brew toolchains disallowed virtual methods, etc.
Thank you,
Gili
Most people won't be using exceptions, so disabling them makes sense (because of them performance and size overhead). This applies to RVCT - no idea what WinARM does here.
No BREW toolchain disallows virtual methods AFAIA, but the vtable layout on RVCT 1.2 doesn't match the C++ ABI, which may be what you mean.
I don't know the answers to your WinARM questions.

cowwoc wrote:Why are exceptions disabled out of the box? Where can I read more about WinARM? I am finding it very short on documentation. Where are the limitations of WinARM documented? Can I use full-fledged ISO C++ on it or does it have some limitations? I remember reading that older Brew toolchains disallowed virtual methods, etc.
Thank you,
Gili
Most people won't be using exceptions, so disabling them makes sense (because of them performance and size overhead). This applies to RVCT - no idea what WinARM does here.
No BREW toolchain disallows virtual methods AFAIA, but the vtable layout on RVCT 1.2 doesn't match the C++ ABI, which may be what you mean.
I don't know the answers to your WinARM questions.

ZeroCool wrote:We have been using RVDS 3.0 (the full version) for the last year. We don't use exceptions, but we are very heavy in our template use. So far we have not found anything that is not supported.
In our experience RVDS 3, or the new RVCT 3, is VERY solid and extremely beneficial. The Edison Design Group front end is first class and really ensures that your C++ will be compiled correctly.
The yearly fee is definitely a cause for frustration. However, $1500/yr or $6k flat is well worth it when you consider the time spent getting something else to work and then finding some random bug right before you plan to ship.
Time is money, and nothing can kill you like a tool chain bug.
Could you please tell me which version of BREW SDK with RVDS 3.0? As far I know it requires BREW 3.1.5 SDK? Were you able to compile any version lower than 3.1.5?

ZeroCool wrote:We have been using RVDS 3.0 (the full version) for the last year. We don't use exceptions, but we are very heavy in our template use. So far we have not found anything that is not supported.
In our experience RVDS 3, or the new RVCT 3, is VERY solid and extremely beneficial. The Edison Design Group front end is first class and really ensures that your C++ will be compiled correctly.
The yearly fee is definitely a cause for frustration. However, $1500/yr or $6k flat is well worth it when you consider the time spent getting something else to work and then finding some random bug right before you plan to ship.
Time is money, and nothing can kill you like a tool chain bug.
Could you please tell me which version of BREW SDK with RVDS 3.0? As far I know it requires BREW 3.1.5 SDK? Were you able to compile any version lower than 3.1.5?

ruben wrote:Could you please tell me which version of BREW SDK with RVDS 3.0? As far I know it requires BREW 3.1.5 SDK? Were you able to compile any version lower than 3.1.5?
And Qualcmm's Elf2Mod works just fine?

ruben wrote:Could you please tell me which version of BREW SDK with RVDS 3.0? As far I know it requires BREW 3.1.5 SDK? Were you able to compile any version lower than 3.1.5?
And Qualcmm's Elf2Mod works just fine?

Where can we read more about the Edit Design Group front end? That comes with RVCT 3.0 or just RVDS?
ZeroCool wrote:We have been using RVDS 3.0 (the full version) for the last year. We don't use exceptions, but we are very heavy in our template use. So far we have not found anything that is not supported.
In our experience RVDS 3, or the new RVCT 3, is VERY solid and extremely beneficial. The Edison Design Group front end is first class and really ensures that your C++ will be compiled correctly.
The yearly fee is definitely a cause for frustration. However, $1500/yr or $6k flat is well worth it when you consider the time spent getting something else to work and then finding some random bug right before you plan to ship.
Time is money, and nothing can kill you like a tool chain bug.

Where can we read more about the Edit Design Group front end? That comes with RVCT 3.0 or just RVDS?
ZeroCool wrote:We have been using RVDS 3.0 (the full version) for the last year. We don't use exceptions, but we are very heavy in our template use. So far we have not found anything that is not supported.
In our experience RVDS 3, or the new RVCT 3, is VERY solid and extremely beneficial. The Edison Design Group front end is first class and really ensures that your C++ will be compiled correctly.
The yearly fee is definitely a cause for frustration. However, $1500/yr or $6k flat is well worth it when you consider the time spent getting something else to work and then finding some random bug right before you plan to ship.
Time is money, and nothing can kill you like a tool chain bug.

Hey Ruben,
We have successfully compiled and shipped apps on BREW 2.0.2 phones using RVDS 3.0. I believe they were compiled against the BREW 2.1.3 SDK. As far as we have been able to tell, the ARM compiler has no dependency on the BREW SDK.
Cheers,

Hey Ruben,
We have successfully compiled and shipped apps on BREW 2.0.2 phones using RVDS 3.0. I believe they were compiled against the BREW 2.1.3 SDK. As far as we have been able to tell, the ARM compiler has no dependency on the BREW SDK.
Cheers,

Well, actually, we found a bug in elf2mod. You probably won't run into it, (it was a year of use before we encountered it), but there is an issue in zeroing out the Z section of the binary. Due to a type oversite, only 1/4 of the section is properly zeroed.
Qualcomm is aware and will be releasing an update within a month or so. The bug has been fixed and is just going through testing.
I would just google EDG....

Well, actually, we found a bug in elf2mod. You probably won't run into it, (it was a year of use before we encountered it), but there is an issue in zeroing out the Z section of the binary. Due to a type oversite, only 1/4 of the section is properly zeroed.
Qualcomm is aware and will be releasing an update within a month or so. The bug has been fixed and is just going through testing.
I would just google EDG....

ZeroCool wrote:Well, actually, we found a bug in elf2mod. You probably won't run into it, (it was a year of use before we encountered it), but there is an issue in zeroing out the Z section of the binary. Due to a type oversite, only 1/4 of the section is properly zeroed.
Qualcomm is aware and will be releasing an update within a month or so. The bug has been fixed and is just going through testing.
I would just google EDG....
Maybe we have not explored the full power of EDG, but it feels like LINT on steroid :D

ZeroCool wrote:Well, actually, we found a bug in elf2mod. You probably won't run into it, (it was a year of use before we encountered it), but there is an issue in zeroing out the Z section of the binary. Due to a type oversite, only 1/4 of the section is properly zeroed.
Qualcomm is aware and will be releasing an update within a month or so. The bug has been fixed and is just going through testing.
I would just google EDG....
Maybe we have not explored the full power of EDG, but it feels like LINT on steroid :D

ZeroCool,
I'm just now getting a chance to evaluate RVDS3. It looks good but this stuff about the vtables and ABI and stuff I don't understand. I do know that as is my applications will not compile as when I go to link there are undefined vtable symbols.

ZeroCool,
I'm just now getting a chance to evaluate RVDS3. It looks good but this stuff about the vtables and ABI and stuff I don't understand. I do know that as is my applications will not compile as when I go to link there are undefined vtable symbols.

Warning: L6310W: Unable to find ARM libraries.
Error: L6218E: Undefined symbol vtable for __cxxabiv1::__si_class_type_info (referred from DeviceCanvas.arm.o).
Error: L6218E: Undefined symbol vtable for __cxxabiv1::__class_type_info (referred from Game.arm.o).
Error: L6218E: Undefined symbol vtable for __cxxabiv1::__vmi_class_type_info (referred from Game.arm.o).
Error: L6218E: Undefined symbol __aeabi_idivmod (referred from Game.arm.o).
Hmm... how do I point it to the arm libraries...and where are they?

Warning: L6310W: Unable to find ARM libraries.
Error: L6218E: Undefined symbol vtable for __cxxabiv1::__si_class_type_info (referred from DeviceCanvas.arm.o).
Error: L6218E: Undefined symbol vtable for __cxxabiv1::__class_type_info (referred from Game.arm.o).
Error: L6218E: Undefined symbol vtable for __cxxabiv1::__vmi_class_type_info (referred from Game.arm.o).
Error: L6218E: Undefined symbol __aeabi_idivmod (referred from Game.arm.o).
Hmm... how do I point it to the arm libraries...and where are they?

The install will have defined an environment variable $RVCT30LIB
link with --libpath c:\progra~1\arm\blah as per RVCT30LIB

The install will have defined an environment variable $RVCT30LIB
link with --libpath c:\progra~1\arm\blah as per RVCT30LIB