Multi Platform Development

[dna]

Hello.

Does anyone know if Fred intends to 'Jump on the Bandwagon' and make Purebasic capable of coding for mobile devices.
(iPad, iPhone, Xoom, etc.)?

[J. Baker]

Hello.

Does anyone know if Fred intends to 'Jump on the Bandwagon' and make Purebasic capable of coding for mobile devices.
(iPad, iPhone, Xoom, etc.)?

I don't think he does but could be wrong. His latest response of having to work a normal job and continue PB is already a lot of work.

[USCode]

He doesn't have to do anything, except continue to make PB better, as next year (hopefully) true x86 Windows tablets are coming to us!
http://microsoft-news.com/intel-our-win ... be-better/
All our PB Windows apps will run on the new tablets. If they can get the same battery life, ease of use, AND with legacy Windows app support, there'd be no reason to mess around with webOS, ARM, etc.

See discussion here:
http://www.purebasic.fr/english/viewtop ... 30#p357419

[moogle]

Yeah I think I'd rather have them stay on working with the current platforms and making them all equal and better than add another workload. If you want to program android/ios and others then take up objective C.

You may get used to it and switch to C\C++

[dna]

Oh.

I never knew he has found more work. I'll drop the notion for about 6 months since things can change.

[wilbert]

Why would PureBasic support touch devices if it's all about cross platform coding.
That makes little sense. Touch, swipe, pinch etc. is so different compared to using a mouse.
For mobile devices, it's important to support the sensors it has like the angle the device is held. Mobile apps don't use windows, they have limited file access etc. There are so many differences.

[Tenaja]

Why would PureBasic support touch devices if it's all about cross platform coding.
That makes little sense. Touch, swipe, pinch etc. is so different compared to using a mouse.
For mobile devices, it's important to support the sensors it has like the angle the device is held. Mobile apps don't use windows, they have limited file access etc. There are so many differences.

True, but the biggest difference is where the growth is. ARM installs are exploding, whereas if the x86 growth hasn't stopped, at the least its growth is stunted.

[wilbert]

I know the market for Android and iOS is huge.
I just don't see why someone would want to use PureBasic to develop for those platforms.
What use is a programming language from the iOS / Android developer perspective when it can't access the built in contacts, calendar data, location services etc.
PureBasic is great but I can see no way how it could be cross platform when you would target iOS and Android.

[Zach]

I think x86 Tablet / Netbook market penetration will suit us all just fine.

Intel has its own Store for Netbooks in beta doesn't it? Think of the untapped resource of customers for quick and easy apps, or light casual games.

So, I don't think multi-platform has to necessarily mean supporting different architectures.

Between X86 Windows/Linux & Macs, plus Laptop/Netbook platforms for all 3 of those OS's I think that is plenty of multi-platform for now.

Sure, iPhones & other mobile devices are all the rage, but I think that is too much to expect from one man, who has clearly set boundaries and priorities for how he wants Purebasic to develop, and the time he wants to spend (or not spend) doing it.

[Thorium]

I think PureBasic would be sweet for smartphone and gaming handheld development. At least for games, you dont need to access contacts and such. For multitouch and additional sensors new libs could be made. I dont see the problem. Sprite Lib would need a OpenGL ES subsystem and all would be fine for me. The only problem is the amount of work to make it happen.

I dont see x86 overtaking the handheld market. Atom is a nice try but no competition for ARM. It can be used in "big" devices like netbooks, but for smartphones or gaming handhelds it would kill battery life. ARM still has a much better balance between power consumption and performance. On x86 this is extremly hard to beat by design, not only but part because of the legacy support.

[USCode]

I think PureBasic would be sweet for smartphone and gaming handheld development. At least for games, you dont need to access contacts and such. For multitouch and additional sensors new libs could be made. I dont see the problem. Sprite Lib would need a OpenGL ES subsystem and all would be fine for me. The only problem is the amount of work to make it happen.

I dont see x86 overtaking the handheld market. Atom is a nice try but no competition for ARM. It can be used in "big" devices like netbooks, but for smartphones or gaming handhelds it would kill battery life. ARM still has a much better balance between power consumption and performance. On x86 this is extremly hard to beat by design, not only but part because of the legacy support.

This is what Intel is working to address. They're working on more-efficient x86 designs. So in essence, you'll get the both of both worlds - a small, efficient tablet AND legacy x86 software support.
Why buy an ARM tablet when you can have an x86 tablet with all the same advantages, plus it runs legacy software. Whether they actually pull it off remains to be seen but when you have the awesome engineering resources that Intel has, I wouldn't bet against them! Their new ultra-thin reference laptop designs will be available soon as well.

See: http://microsoft-news.com/intel-our-win ... be-better/

[Thorium]

This is what Intel is working to address. They're working on more-efficient x86 designs. So in essence, you'll get the both of both worlds - a small, efficient tablet AND legacy x86 software support.
Why buy an ARM tablet when you can have an x86 tablet with all the same advantages, plus it runs legacy software. Whether they actually pull it off remains to be seen but when you have the awesome engineering resources that Intel has, I wouldn't bet against them! Their new ultra-thin reference laptop designs will be available soon as well.

See: http://microsoft-news.com/intel-our-win ... be-better/

You are right, but only if they realy can beat ARM, the guys at ARM not sleeping either. Highly efficient 2Ghz dual core ARM designs are actualy out now. Not in high availablity because the manufacturers like TI need to keep up with ARMs development. But it's a hard nut to crack for Intel.

We will see what will happen. A x86 tablet is a nice thing, it's still big enough for a powerfull battery, but i dont think we will see actual x86 smartphones.

[USCode]

You are right, but only if they realy can beat ARM, the guys at ARM not sleeping either. Highly efficient 2Ghz dual core ARM designs are actualy out now. Not in high availablity because the manufacturers like TI need to keep up with ARMs development. But it's a hard nut to crack for Intel.

We will see what will happen. A x86 tablet is a nice thing, it's still big enough for a powerfull battery, but i dont think we will see actual x86 smartphones.

Couldn't agree more. Intel will need to leapfrog the current ARM-compatible offerings in order to be competitive when the new x86 offerings are actually released.
I believe Intel has had enough competition over the years to realize this. Afterall, it was an Intel co-founder and former CEO that wrote a book "Only the Paranoid Survive"!
http://www.amazon.com/Only-Paranoid-Sur ... 0385482582

[Thorium]

You are right, but only if they realy can beat ARM, the guys at ARM not sleeping either. Highly efficient 2Ghz dual core ARM designs are actualy out now. Not in high availablity because the manufacturers like TI need to keep up with ARMs development. But it's a hard nut to crack for Intel.

We will see what will happen. A x86 tablet is a nice thing, it's still big enough for a powerfull battery, but i dont think we will see actual x86 smartphones.

Couldn't agree more. Intel will need to leapfrog the current ARM-compatible offerings in order to be competitive when the new x86 offerings are actually released.
I believe Intel has had enough competition over the years to realize this. Afterall, it was an Intel co-founder and former CEO that wrote a book "Only the Paranoid Survive"!
http://www.amazon.com/Only-Paranoid-Sur ... 0385482582

I am working with ARMv7 ASM the last days. And the more i work with it the more i realize that Intel cant beat them with x86. ARM is way more efficient just by design. To make x86 as efficient or even more efficient would mean a complete redesign of the instruction set and drop of support for legacy instructions.

The first thing thats much better on ARM is the instruction encoding. They have a very clear and well structured fixed length encoding, that is easy and most importantly fast to decode. The only drawback is that constant values can only be encoded with 12 or 16 bit depending on the instruction. So if you need a constant value bigger than 12 bit you need to construct it by using one or two additional instructions.
Compare this to the x86 instruction encoding: It's a real mess. We have variable length instruction encodings, which offer us any size of constant up to the biggest register size. However that makes it harder and slower to decode. Than we have binary compatiblity to legacy x86 instructions, which forces the need of prefixes for newer instructions, again complicating the decoding and slowing it down.

Second thing is: Most ARM instructions are none destructive. Thats realy great stuff. On x86 you commonly need to preserve registers because they get overwritten by instructions. On ARM you can specify a seperate destination register and dont need to overwrite any of the operands. In practise that saved me a lot of instructions allready and lowers the count of needed registers on many algos.

In addition ARM offers the option to bit shift one of the operands on most operations, without needing a single cycle more for the operation. If you need to do a add operation, a bit shift (multiplicate/devide by power of two) and preserve the operands, well that needs only one cycle on ARM!

Especialy the none destructive instruction design is so awesome, intel is actualy implementing that on x86 right now with new instruction set extensions, however that does nothing for legacy applications.

Memory accesses seem to be much better on x86 as most instructions can pull at least one operand directly from memory.
On ARM no instruction can do that. You need to load them first to a register. But it makes up for that by having more registers.

[USCode]

It's amazing the creative solutions some folks are able to come up with. There have been lots of superior competitors to x86 that have come and gone. Only time will tell what the future holds.