How cumbersome is it to write code that will run on both x86 and ARM?

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

what the hell is ARM?

cross-architecture is pretty easy these days, if you stay in userspace.
cross-OS is still hard.

I was planning on using c++. Since almost every c++ program is also a c program it should be the same right?

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.

C++ is not C.

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

for the sake of portability he will face exactly the same problems

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.

>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.

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)

not if he rows his own file or network protocol, a simple
uint32_t version = 4;
fwrite(&version, 1, 1, fopen("file.bin", "w"));

is enough to "trigger" such problem

I definitely remember Bjarne mentioning that, with a few exceptions, c++ programs are also c programs.

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.

Any good books on C/C++ for ARM?

>Looks like I'll have to read on endian aware code.
that's not a big deal, actually, like 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

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

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 ).

what are you doing in Sup Forums again?misclicked and thats why you are on Sup Forums instead /hm/?

Probably another Sup Forumsydiot that got lost from his nvidia dick sucking threads.

java?

I think he was talking about C++.

No its better

>amdrone buttblasted for no reason

> 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.

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.

>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.

Get out tech illiterate

ARM != tablet

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.