How cumbersome is it to write code that will run on both x86 and ARM?
What's the current state of freedom on tablets?
I like using my smartphone for a lot of small things that don't require powering my workstation, but the fact that I don't have control over it bothers me. In the future I would just like to buy a tablet and put Debian(ARM) on it and have the same control that I have over my regular machine, like coding what I want for it, full hardware access etc. How possible is that at the moment?
just program in c, and you'll be fine
>>60384277
what the hell is ARM?
>>60384277
cross-architecture is pretty easy these days, if you stay in userspace.
cross-OS is still hard.
>>60384369
I was planning on using c++. Since almost every c++ program is also a c program it should be the same right?
>>60384387
I don't plan on writing drivers and like I said I would like a free tablet to install Debian on. I remember years ago the x86 Jolla tablet came out but unfortunately it didn't catch on. The only option I see these days is a free ARM tablet or to root a non-free one.
>>60384492
C++ is not C.
>>60384492
what the other guy said
if you are running the "same os" is kinda easy
if not, you have to iron out differences from Android and GNU/Linux, which can become complicated
other than that, just pay attention that while most ARMs can work as both, big and little endian, it becomes set to work as big endian
while x86 (even 64) are little endian
so you have to write endian aware code, specially if you want to communicate with other devices or transfer files between them
>>60384525
for the sake of portability he will face exactly the same problems
>>60384277
It wouldn't be problem if OS support & language support were the same across both architectures.
If Windows 10 vanilla comes to ARM, it would be insane for them to not add C# VM to ARM.
Otherwise, no. Android Java is nothing like Enterprise Java.
I assume the same is true for Objective C.
>>60384545
>so you have to write endian aware code, specially if you want to communicate with other devices or transfer files between them
Most of low-level IO shit like this is abstracted out by the underlying IO libraries.
There is very little chance of anyone actually needing to consider bit flipping because of endian differences.
>>60384492
when developing on non-x86 platforms avoid unaligned reads and writes like a plague, if you really must do some use memcpy/memset as they are the only portable way to do so, as your compiler will figure out the safest way to do it
they are not only incredible slow, they also rises CPU/BUS exceptions on many architectures (ARM/MIPS specially)
>>60384583
not if he rows his own file or network protocol, a simpleuint32_t version = 4;
fwrite(&version, 1, 1, fopen("file.bin", "w"));
is enough to "trigger" such problem
>>60384525
I definitely remember Bjarne mentioning that, with a few exceptions, c++ programs are also c programs.
>>60384545
I definitely plan on using the same OS although I don't know the state of Debian ARM.
>so you have to write endian aware code, specially if you want to communicate with other devices or transfer files between them
Transferring files will definitely be a thing. Looks like I'll have to read on endian aware code.
>>60384692
Any good books on C/C++ for ARM?
>>60384805
>Looks like I'll have to read on endian aware code.
that's not a big deal, actually, like >>60384583
said, if you use some libraries they will do it for you, otherwise, other than that is just wrap your int reads and writes with ntohl (Network to Host Large) htonl (Host to Network Large) and alike functions
those names are due big endian been also known as Network endian/bite order
i never read any book about C/C++ dev on ARM, and i doubt that there is many (if there is any at all)
since C/C++ is mostly about abstracting machine code, to make it portable
such thing about unaligned memory access, are a thing that all CPUs architectures suffers, but it's treated more gracefully on x86 than others archs (at a huge performance hit)
that's really a hit and miss issue, specially dependent on arch and compiler
>>60384805
I think you mean that C programs are C++ programs. As the name implies, cpp is supposed to be an extension of C. You can't compile a class in C but you can printf() in cpp
>>60384934
So the coding gap between architectures won't be difficult. The only thing left now is to establish how free would a rooted tablet be, because I don't expect to see Linux Tablets any time soon ( I'm not counting Android because of how closed it is ).
>>60384376
what are you doing in /g/ again?misclicked and thats why you are on /g/ instead /hm/?
>>60386448
Probably another /v/ydiot that got lost from his nvidia dick sucking threads.
>>60384387
java?
>>60389314
I think he was talking about C++.
>>60384525
No its better
>>60387605
>amdrone buttblasted for no reason
>>60384277
> How cumbersome is it to write code that will run on both x86 and ARM?
I don't know, but I remember I tried to compile an I2P written in C on an ARM rouler (armel). It compiled, but I couldn't run it due to an outdated kernel. Anyway, check Debian ARM project, there's a ton of software.
>>60391417
Actually I've used NVIDIA cards all my life and before them I had a Riva TNT.
I still hate NVIDIA and consumerism with a passion. Wasting money on the latest CPU/gpu just to brag about it is retarded.
>>60391448
>Anyway, check Debian ARM project, there's a ton of software.
I've glanced at it but the only way to know how it would work is to actually put it on a tablet and see. I don't think the FS community cares much about ARM because, I don't see much push from them for a FREE tablet.
>>60384376
Get out tech illiterate
>>60391669
ARM != tablet
>>60392865
Yes, thank you, I know that, but it's tablets that are going to replace desktops and laptops for normies so they should be the nr 1 focus.