Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

ARM Launches Juno Reference Platform For 64-bit Android Developers

samzenpus posted about a month ago | from the check-it-out dept.

Android 69

MojoKid writes One of the trickiest aspects to launching a new platform update is the chicken and egg problem. Without any hardware to test on, developers are leery of committing to supporting new hardware features. Without software that takes advantage of new hardware capabilities, customers aren't willing to pay for new equipment. This is the crux of the issue with respect to the ARMv8 architecture and enabling development for 64-bit Android platforms. As such ARM is readying their Juno development platform that combines several of ARM's most advanced technologies on a single board. The product supports big.Little in an asymmetric configuration; each board ships with two Cortex-A57s, four Cortex-A53s, and a modest Mali T-624 core. All this hardware needs an OS to run on — which is why ARM is announcing a 64-bit port of Android as part of this new development board. By including AOSP support as well as additional hooks and features from Linaro, ARM wants Juno to be a sort-of one-stop shopping product for anyone who needs to test, prototype, or design a 64-bit product for the ARM ecosystem. The Android flavor that's coming over is based on Linaro Stable Kernel 3.10. At launch, Juno will support OpenGL-ES 3.0, on-chip thermal and power management, up to 8GB of RAM (12.8GB/s of bandwidth), an optional FPGA, and USB 2.0. OpenCL 1.1 will be added in a future product update. The project is positioned as a joint ARM / Linaro launch with ARM handling the hardware and Linaro taking responsibility for the software stack.

cancel ×

69 comments

What the fuck is this thing? (-1)

Anonymous Coward | about a month ago | (#47373091)

This is a remarkably shitty summary, even by Slashdot's shitty, shitty standards.

Is it just yet another reference board like CPU vendors have been released for decades now?

Is there actually anything special about it? It all sounds rather typical to me.

Re:What the fuck is this thing? (4, Informative)

MtHuurne (602934) | about a month ago | (#47373127)

Yes, it's a reference board. What's new about it is that it contains a 64-bit ARM processor.

For what it's worth, I thought the summary was very informative.

Re:What the fuck is this thing? (1)

Anonymous Coward | about a month ago | (#47373165)

What's special about a 64-bit ARM processor? Haven't they been in iPhone 5S phones for almost a year now?

Re:What the fuck is this thing? (5, Funny)

K. S. Kyosuke (729550) | about a month ago | (#47373215)

Yes, but now there's a chance to get them in actually useful devices.

Re:What the fuck is this thing? (0)

Anonymous Coward | about a month ago | (#47373351)

All I see mentioned is Android. Where's the announcement of these useful devices you mention?

Re:What the fuck is this thing? (-1)

Anonymous Coward | about a month ago | (#47373405)

Take off your iBlinders, you'll see. iDiot.

Re:What the fuck is this thing? (-1)

Anonymous Coward | about a month ago | (#47373481)

Why would I use an iFag phone? That's the only mobile OS capable of being more useless than Android.

Re:What the fuck is this thing? (1)

K. S. Kyosuke (729550) | about a month ago | (#47373725)

Whatever useful appliances with embedded ARMs the engineers are going to design, of course.

Re:What the fuck is this thing? (0)

Anonymous Coward | about a month ago | (#47373547)

Then watch Samsung fuck it up. Nexus or nothing.

Re:What the fuck is this thing? (3, Interesting)

tlhIngan (30335) | about a month ago | (#47374093)

What's special about a 64-bit ARM processor? Haven't they been in iPhone 5S phones for almost a year now?

Well, Apple pretty much skunked everyone, because the roadmaps for 64-bit ARM processors had them sampling middle of 2014, for release end of 2014. These were roadmaps published by Qualcomm, Broadcom and everyone else.

So Apple pretty much got a year and a half head start (devices weren't to ship until mid 2015).

Oh, Android for 64-bit ARM wasn't supposed to be out until end of 2014, either.

Which meant if you really wanted, you shouldn't buy a phone in 2014 because what made the iPhone and iPad so fast WAS 64-bit. ARMv8 is much more efficient - 32 bit code gets a minor speedup, but the 64-bit stuff runs WAY faster.

Re:What the fuck is this thing? (-1)

Anonymous Coward | about a month ago | (#47374181)

what made the iPhone and iPad so fast WAS 64-bit.

Actually, it was their relatively low resolution display and their improved graphics chips combined with OpenGL ES 3.0.

Apple is smart to lay the foundations for 64-bit mobile computing now, since 64 bit addressing is important if you want more than 4GB RAM, but the iPhone only has 1GB, so the 64 Bit tag is mostly marketing.

Re:What the fuck is this thing? (3, Insightful)

fnj (64210) | about a month ago | (#47374279)

since 64 bit addressing is important if you want more than 4GB RAM

64 bit direct addressing is no more necessary to use >4 GB of RAM with ARM than it is with Intel. The magic is called PAE - physical address extension. It allows a multiple of 4 GB of RAM globally, though each process is, in practical terms, limited to 4 GB. For example, the Cortex-A12 core is a 32 bit architecture, but has 40 bits of memory addressability. 32 of those bits are directly set from address fields in instructions, and the other 8 bits are set by page tables. With 40 bits you can utilize up to 1 TB of RAM.

Those old enough to remember the 8086 will recall that it was a 16 bit architecture, but had 20 address pins, so could address 1 MB of RAM rather than just 64K. 4 of those pins were set using segment registers. The segmented memory model was actually more flexible than the flat memory model, because even individual processes could manipulate their own segment registers to address the full 1 MB range.

Re:What the fuck is this thing? (1)

marcovje (205102) | about a month ago | (#47374509)

PAE is mostly for kernels and a few select apps that page out buffers (like SQL Server). It is not a general flat >4GB memory space for applications.

And yes I remember how it was with the 8086. Which is why I try to forget segmentation for general purpose programming :-)

Re:What the fuck is this thing? (0)

Anonymous Coward | about a month ago | (#47374777)

The segmented memory model was actually more flexible than the flat memory model, because even individual processes could manipulate their own segment registers to address the full 1 MB range.

That is a bit like saying that it is better to be stuck in a well since you then can climb out of it.

Re:What the fuck is this thing? (1)

stalky14 (574130) | about three weeks ago | (#47378869)

+1, sir, would that I could!

I remember learning x86 assembly after knowing 6502, 68000, and 68HC11 and wondering what it was the Intel engineers were smoking when they came up with not just the addressing scheme, but little-endian (don't get me started), and destination, source! More importantly, WHY that became the most popular architecture. It's like everything was upside-down and backwards of what I learned.

Though from what I've seen, ARM is little-endian and dest,src too, probably to appease people coming over from Intel.

Re:What the fuck is this thing? (0)

Anonymous Coward | about three weeks ago | (#47379873)

There is the reasonable justification that having the destination operand first has greater consistency since the number of source operands is variable. Despite being something you have to be prepared for little-endian versus big-endian doesn't really effect code too much anywhere.

Meanwhile, anyone who suggests segmentation as a reasonable approach to anything needs to be shot well before sight. If you see them you're already dead. Just say NO to segmentation! This is kind of like the people who "merely" suggest adding an octect onto IPv4 addresses, you instantly know they know nothing about the actual protocols.

CAPTCHA: baffler

Re:What the fuck is this thing? (1)

stalky14 (574130) | about three weeks ago | (#47387075)

Hmmm... I agree with you about segmentation, but think that adding an octet or two to IP4 would be vastly preferable to the unreadable, unmemorizable, mess that is IP6 that makes us slaves to domain name servers. So make it a non-lethal shot, please!

Re:What the fuck is this thing? (2)

jeremyp (130771) | about a month ago | (#47375003)

The segmented memory model was actually more flexible than the flat memory model, because even individual processes could manipulate their own segment registers to address the full 1 MB range.

Should really be written

The segmented memory model was actually less flexible than the flat memory model, because individual processes had to manipulate their own segment registers to address the full 1 MB range.

There's no doubt that, from the point of view of a programmer, the flat memory model is simpler and more flexible. You only have to see the kludges that 8086 C compilers introduced to make the full 1 Megabyte available to C programmers to understand that. Also check out every operating system, designed for the 386 and up which immediately set all the segment registers to point to segments that were 4Gb in size and that started at address 0.

Re:What the fuck is this thing? (1)

_Shad0w_ (127912) | about a month ago | (#47374443)

The main reason to move to 64-bit isn't memory, it's address space. Some other useful things falls out of it in a co-incidental kind of way too, like more registers (which are nice for tight loops).

Re:What the fuck is this thing? (1)

RyuuzakiTetsuya (195424) | about a month ago | (#47374821)

I hate replyin to ACs. But, no. What sped up the iPhone and iPad Air wasn't the low resolution. We aren't talking about gamin or graphics performance, we are talking about raw CPU performance.

The transition to 64 bit wasn't the secret sauce, the secret sauce was that a lot of legacy CPU behavior in 32 bit mode went away. So when running in pure 64 bit mode, the CPU was way more efficient.

It's like the x64 transition.

Re:What the fuck is this thing? (0)

Anonymous Coward | about a month ago | (#47375007)

Also afaik Arm64 added a lot of features, made vector math obligatory and dumped Thumb-mode.

Sorry to reply as anonymous; I just stopped giving a shit about /. a couple of years back. If my login is still around it has excellent karma.

Re:What the fuck is this thing? (1)

slashdice (3722985) | about a month ago | (#47375921)

There's also a new 64-bit Objective C runtime. It has better performance than the 32-bit version but isn't a drop-in replacement. Since everything needs to be re-compiled and re-tested for 64-bit support, they can make add the new runtime without breaking existing 32-bit applications.

Re:What the fuck is this thing? (1)

AmiMoJo (196126) | about a month ago | (#47374909)

The nice thing about Android is that most apps will get an immediate re-compilation to 64 bit by the device and benefit from the full speed boost, without any need for the developer to act. Apps that use native code will need to be re-compiled of course.

Re:What the fuck is this thing? (0)

Anonymous Coward | about a month ago | (#47374933)

What?!

According to the Fandroids around here, I thought 64-bit was useless unless you needed more than 4GB of RAM! Why do I have a feeling the exact same people are going to be extolling the virtues of 64-bit ARM as being revolutionary and absolutely necessary when it shows up in a Samsung / HTC / LG / Motorola device?

(Yes, it was stupid a year ago, and it's still stupid today. Just the same as it was stupid to say that in 1996 when DEC had the 64-bit Alpha that only the highest end configurations got close to 4GB of RAM)

Re:What the fuck is this thing? (-1)

Anonymous Coward | about a month ago | (#47374019)

Yeah, no thanks, I'll stick with a proper CPU from Intel.

Re:What the fuck is this thing? (1)

Anonymous Coward | about a month ago | (#47373137)

I gathered from the summary that it is a dev board to bootstrap/showcase ARMv8 (64-bit ARM) arch development. Vendors will have their own dev boards with their own SoCs, I'm sure. But they will expect you to be plugged into their ecosystem and tough going if you aren't.

Seemed obvious.

Re:What the fuck is this thing? (0)

Anonymous Coward | about a month ago | (#47373345)

ARMv8 (64-bit ARM)

So it's time for Google to step up to the plate. How long will it be until we get v8 [google.com] for the v8?

Re:What the fuck is this thing? (1)

aztracker1 (702135) | about a month ago | (#47374321)

well considering the target is android, you'll get v8 under the chrome browser.. beyond that, you can probably get node.js running in it.

Re:What the fuck is this thing? (0)

Anonymous Coward | about a month ago | (#47373355)

The real story:

        By including AOSP support as well as additional hooks and features from Linaro

They never offereed a dev platform before. Now they do. And its their first 64 bit reference targeting the mass android market.

The end.

Re:What the fuck is this thing? (1)

Desler (1608317) | about a month ago | (#47373495)

ARM has sold dev boards for ages.

Re:What the fuck is this thing? (1)

fuzzyfuzzyfungus (1223518) | about a month ago | (#47374417)

The only major difference is that (in an effort that started before this board came out, and which they've pushed hardest for their 64-bit design, though the assorted ARM licencees seem to be tiring a bit of pointless differentiation on their own) ARM has recently been trying to stamp out some of the vendor-specific weirdness that has historically surrounded the architecture.

Presumably building "ARM's reference board", rather than letting the licensees of the A57 spawn theirs and leaving it at that, is part of their effort to ensure that crazy stuff like 'actually being able to boot without a blood-oath and a BSP' works across ARM based systems.

That's one thing that, while stultifying in many respects, the 'wintel' duopoly did for x86. Nothing stops an x86 CPU from being extremely weird (and there are a few oddities available) but the 'if it can't boot Windows it might as well not be an x86...' demands of the market, along with the fact that (unlike even MS' embedded OSes, never mind the embedded industry at large) 3rd parties pretty much don't get to touch Windows' internals until it has booted up far enough to load device drivers, has driven (ugly, hacky, largely de-facto) 'standardization'. ARM? Not. So. Much, something that they are trying to change at least for their more powerful parts.

This summary is TOTAL SHIT. (-1)

Anonymous Coward | about a month ago | (#47373101)

For crying out loud, this summary is pretty much the entire article. What a piece of shit summary! The article isn't very good, either. The picture of the board is a lot more interesting than any of the utter crap commentary surrounding it. And why the fuck is a big part of the text nothing but an image of a presentation slide or something like that? There's a hyperlink shown in it, but you can't actually click on it, because the text is part of a goddamn image! I mean, seriously! What the fuck! Why is this total crap even on Slashdot's front page?

Re:This summary is TOTAL SHIT. (1)

jones_supa (887896) | about a month ago | (#47373325)

Its-a-me, Mario! Wahuu!

Official ARM Link (1)

Monkius (3888) | about a month ago | (#47373155)

http://arm.com/products/tools/development-boards/versatile-express/index.php

Re:Official ARM Link (4, Informative)

imroy (755) | about a month ago | (#47373283)

Or more specifically: http://www.arm.com/products/to... [arm.com]

Re:Official ARM Link (0)

Anonymous Coward | about a month ago | (#47373513)

As I have been chastised before, "No, that's a URL. This is a link: http://arm.com/products/tools/development-boards/versatile-express/index.php [arm.com] "

Juno SoC? (1)

imroy (755) | about a month ago | (#47373273)

Wait... is ARM making its own chip? I don't think they've done that since like the ARM1/2.

Re:Juno SoC? (1)

Alioth (221270) | about a month ago | (#47377077)

ARM didn't make the ARM1/2 either, they were fabricated by VLSI (the company, not the acronym). ARM has always been fabless.

Re:Juno SoC? (1)

imroy (755) | about a month ago | (#47377365)

By that measure, isn't AMD also fabless because TSMC makes their chips? (or at least their big processors)

I guess what I mean by "making" is "designing and having someone fabricate for them". That is what would set it apart from all of the other ARM chips out there today.

Android development guidelines recommend Java (1)

InvalidError (771317) | about a month ago | (#47373315)

If developers do not want to worry about the underlying hardware, all they need to do is stick to Google's developer guidelines and use Java. Let the JRE and native recompiler abstract all the hardware-dependent stuff. Not quite as compute/power-efficient (at least in theory) but from what I have seen, there seems to be tons of developers who waste tons of cycles regardless of portable vs native anyway.

This FP for GNAA (-1, Redundant)

Anonymous Coward | about a month ago | (#47373335)

deliver. Some of will recall that it move any eq%uipment Counterpart,

chicken and egg problem (1)

packrat0x (798359) | about a month ago | (#47373343)

"Without any hardware to test on, developers are leery of committing to supporting new hardware features. Without software that takes advantage of new hardware capabilities, customers aren't willing to pay for new equipment."

Is it not the manufacturer's interest to provide initial software / libraries? At least version 1.0?

What!!!? (1)

Mister Liberty (769145) | about a month ago | (#47373427)

What!!!?
Sixteen posts already and nobody (apart from the sidebar) even mentioned the word Linux?
(Which, kids, surprise, surprise -- is what Android basically is.)

Yes, these days, many of my smart phone addict friends stifle with quite a surprising look when
they hear Android is Linux.

My fellow nerds -- you have an obligation, don't let Google or Samsung get away with this!

Re:What!!!? (1)

dave420 (699308) | about a month ago | (#47374625)

Give it a rest. It's like claiming Einstein was just sandals. There is a bit more to it than just what it's running on, and it's that bit which makes it what it is.

Open Source Drivers? (4, Insightful)

Anonymous Coward | about a month ago | (#47373437)

I'll buy one if ARM publishes the source code to the drivers in an open source license. These Android stacks with binary blobs are nightmares to work with.

Re:Open Source Drivers? (0)

Anonymous Coward | about a month ago | (#47373515)

You realize for that ARM you'll have to give a LEG?

Seriously the board is $$$$$ where $ is a digit...

Re:Open Source Drivers? (1)

blackiner (2787381) | about a month ago | (#47373603)

It is a shame because I find this platform to be rather interesting. I would love to hack around and turn one of these into a router/file server, and see what sort of graphics capabilities it has. No big deal though, cheaper variants will come out sooner or later.

Open Source Drivers? (1)

janoc (699997) | about a month ago | (#47374361)

ARM doesn't build chips, thus no drivers neither. That falls on the silicon vendors - TI, Broadcom, Samsung, etc. They are a pure-IP licensing company.

BTW, their Mali GPUs have open source drivers.

Re:Open Source Drivers? (0)

Anonymous Coward | about a month ago | (#47377193)

ARM doesn't build chips, thus no drivers neither. That falls on the silicon vendors - TI, Broadcom, Samsung, etc. They are a pure-IP licensing company.

BTW, their Mali GPUs have open source drivers.

Not so.

ARM builds both IP and the software necessary to use it.

Re:Open Source Drivers? (0)

Anonymous Coward | about three weeks ago | (#47380567)

The only open source Mali drivers are reverse-engineered (http://limadriver.org/). ARM only open sourced a small kernel-space component. All the good stuff is still in a binary-only blob. (http://www.phoronix.com/scan.php?page=news_item&px=MTY3OTM)

Re:Open Source Drivers? (1)

AmiMoJo (196126) | about a month ago | (#47375127)

ARM only do the reference design for the CPU core. All the peripheral stuff that you need drivers for is designed by other companies. FWIW the core stuff that ARM do is all publicly documented and well supported on OS platforms like Linux/AOSP.

Re:Open Source Drivers? (1)

Narishma (822073) | about a month ago | (#47375633)

They do more than just CPU cores. The GPU in this thing, for example, is from ARM.

Re:Open Source Drivers? (0)

Anonymous Coward | about three weeks ago | (#47380365)

mod this down. You don't know what you are talking about. These boards cost several thousand dollars. They aren't intended for anoymous cowards to hack on.

What are the server options for ARM/Android now? (0)

Anonymous Coward | about a month ago | (#47373467)

I could use an Android/ARM low end server box today. What are the options? 64 bit its fine and all, but I don't need either the processing power or the wider Integer width and don't want to use first generation technology. So I don't see the point in waiting for the A57s/53s boxes, 32 bit A15s are fine.

The App is currently running on Exynos 5 8 core Android tablet with client and server on same tablet. It needs to support multiple clients, the tablet isn't suitable obviously. So I'm looking for something with 8 cores, doesn't have to be the Samsung chip. Android 4.4 would be nice, I'd like a RAID for storage, Gigabit wired network, 2-3GB ram would be fine. Android support is essential, I don't want to mix the development environments, and the apps already written, the client-server split is already in and working.

What's the options?

just curious, why did you choose Android on ARM? (1)

raymorris (2726007) | about a month ago | (#47373563)

I'm just curious - for a server, where you want RAID, gigabit bandwidth, etc, why did you choose Android on ARM as opposed to something like one of the inexpensive AMD offerings with any of the oother small Linux distributions that are more flexible? Those scale anywhere from very low end to 8 cores at 5Ghz and there are all kinds of options for RAID, gigabit or higher networking, etc. Was that because Android tablets made sense for the clients, so you decided to just run both client and server on the same platform?

Re:just curious, why did you choose Android on ARM (0)

Anonymous Coward | about a month ago | (#47373739)

Well today arm on servers don't make a particularly large amount of sense. But common x86 servers have a two sockets, a 12-32 cores, 64GB ram, consume a max of 300-400 watts, have a "free" gigE, take up 0.5 to 1 RU in a rack, and cost approximately $3k.

Sure you can add 10G ethernet, 40G ethernet, or Infiniband, but it's not cheap. Now imagine that a future 64-bit arm chip allows for a system/blade at say 20 watts, quad core 64-bit arm, 40% as fast as a 6 core intel, and cost $600 each in a chassis that holds 16 and takes 2U and uses a 40G uplink.

You end up with better performance per watt, performance per rack unit, and more balanced CPU/Network bandwidth. Lower rack space bills, lower power bills, lower cooling bills, you need less ports on a switch, less cabling, etc.

Sure some will hate it because the cores individually are slower than intel, but others care more about throughput and don't care about microsoft windows compatibility.

Not sure if arm (and partners) will pull it off, but it seems possible.

Re:just curious, why did you choose Android on ARM (1)

aztracker1 (702135) | about a month ago | (#47374339)

The problem is that a quad-core ARM isn't 40% as fast as a 6-core Intel, let alone a dual/quad 8-core AMD... Now, you can do some really cool things with ARM, if there were a decent I/O backplane for a cluster it would be awesome, but most can't even get 40mbps of throughput to a network adapter... When there are systems handling hundreds of thousands of requests per second, ARM won't handle that in its' current state, and those that have tried have been so much more expensive than x86 off the shelf, it won't save enough in power over its' lifetime. Doesn't mean it will always be that way... and yeah, I've looked, and it's cool.. but not worth it (yet).

Re:just curious, why did you choose Android on ARM (0)

Anonymous Coward | about a month ago | (#47375967)

but most can't even get 40mbps of throughput to a network adapter...

Not entirely true.
Samsung Arm Chromebook (Exynos 5250) + 1Gbps USB3.0 adapter, iperf TCP -> 800mbps.

Re:just curious, why did you choose Android on ARM (0)

Anonymous Coward | about a month ago | (#47373801)

It simply developed from being a client side app, with rich tablet interactions, to a larger app shared by people in the office. So it's already Arm and Android, and I don't want to port it or run two different development environments and maintain two different parts on two different OS's. I want to simply move one part over to another box.

I like Android, the scheduling and restarting of my code when it crashes, the separation between GUI components and 'services', intents, easy threads via AsyncTasks, remote installs, and so on. It runs now quietly as a service in the background on a dedicated tablet, with the GUI occasionally interacting with it.

I'm not close-minded to x86 hardware running Android, I see you can get Android ports for PCs and hence for servers, but I have a raid at home (Synology), and it's ARM based, and low powered, it sits quietly on my network reliable, cool, stable, reliable, does masses of stuff, etc. so I have very good experience with Arm boxes already and want to continue that experience.

Ideally, if someone had a port of Android to a Synology raid, I'd go with that. It doesn't have to be a full port, no need for the gui, so no need for all that hardware rendering and OpenGL and so on, but just the Java + Android framework-only would do.

"so you decided to just run both client and server on the same platform"

No, I decided to write a tool for myself on what was then a small 5 inch android tablet, and over the years it grew bigger and did more and others in the office want to use it. It needed upgrades along the way, and Android provided that with bigger screens, more cores, hardwired Ethernet, more ram and so on, as it needed them. Now I want to put a client-server split it in, and run it on multiple clients to a server. My expectation is (based on all the previous upgrades), that this will be possible, or perhaps already is.

I did a test last year using a TV Box (Android Quad core, 2GB ram, Gigabit ethernet, USB drive) and the principle is there, but a crappy Quad core A9 wasn't ideal, and a USB drive is obviously unsuitable. As a test of the principle it was fine, as a production system, obviously not.

So I assume such a system is available, but Google searches for server android and variants give me servers running on Android, the flip of what I want, so is such a box available.

Re:just curious, why did you choose Android on ARM (0)

Anonymous Coward | about a month ago | (#47373979)

Read this raymorris (don't evade it a dozen times and downmod it like you did before) http://it.slashdot.org/comment... [slashdot.org]

Get a set of BALLS raymorris (0)

Anonymous Coward | about a month ago | (#47374077)

Re:Get a set of BALLS raymorris (1)

RyuuzakiTetsuya (195424) | about a month ago | (#47376155)

Either APK is truly sexist, stupid and crazy, or this is a super clever APK troll. Only if we had some sort of way for him to possibly enter credentials verifying it's actually him... :)

Now the big question, is APK sexist, crazy/stupid AND racist? Will he make the ESR hat trick?

Re:Get a set of BALLS raymorris (0)

Anonymous Coward | about a month ago | (#47376783)

Was anyone speaking to you, or are you ray's sockpuppet? We all see raymorris running http://it.slashdot.org/comment... [slashdot.org] from that like the blowhard bigmouth "ne'er do well" coward he's evidencing himself to be.

Re:Get a set of BALLS raymorris (1)

RyuuzakiTetsuya (195424) | about three weeks ago | (#47389277)

Either you're a clever troll or you're too stupid to check post history, etc.

I'll save you the trouble if you're not a troll. I am not raymorris' sock puppet.

What are the server options for ARM/Android now? (1)

slashdice (3722985) | about a month ago | (#47376021)

I have a QNAP ARM-based NAS device. It came with linux+busybox+http server for configuring but it was soon running debian.

I haven't paid attention for a few years, but there were also things like the sheeva plug and gumstix (which can run android).

Opengl... (0)

Anonymous Coward | about a month ago | (#47375169)

Why doesn't it just adopt openGL 4 like tegra k1 did.

The answer is called LLVM (1)

DrXym (126579) | about a month ago | (#47375235)

Instead of expecting developers to support some new architecture, Google, Intel and ARM need to knock heads and implement LLVM as an alternative. Then devs largely DON'T CARE what the backend is - they compile their native code to LLVM bitcode and let the system figure out how to convert it to native instructions. Conversion could even happen in the cloud so the user just downloads an apk which just happens to contain the native binary necessary for their specified device.

The weird thing is Google already support this for Renderscript, but not the NDK where it would be most useful. Encourage people to compile to LLVM and new architectures becomes much less of an issue.

Re:The answer is called LLVM (1)

Xrikcus (207545) | about a month ago | (#47376967)

Google supports LLVM in the NDK. Renderscript is more like OpenCL where they restrict the input to make portability easier. Google also has the portable native client definition that aims to do something more general as you are suggesting, though that's for the desktop not android, admittedly. The thing is that LLVM is not actually portable between 32-bit and 64-bit anyway because C loses too much of that information at the early stages of compilation.

If you look at the SPIR spec (https://www.khronos.org/spir), which is an attempt to write a standardised version of an LLVM subset as you suggest, but for the OpenCL C subset so avoiding some of the complexities, you'll see that there are 32-bit and 64-bit versions and it really relies on the fact that OpenCL defines the sizes and layout of types more strictly than pure C does. LLVM is not a panacea in this case and a browse of past LLVM mailing lists will tell you that many of the devs are not keen on using it for portability because it isn't really what the IR was designed for.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...