SoylentNews is people
SoylentNews
Submitted via IRC for SoyCow8093
Although ARM-based PCs are now available, apps that utilize native 64-bit architectures on Microsoft's Windows 10 on ARM have been relegated to legacy support for 32-bit apps. Microsoft introduced the proper frameworks for 64-bit apps at its recent BUILD conference, allowing developers to port their apps and begin native app integration. After a small wait, apps are starting to appear; VLC -- the swiss army knife of multimedia players -- is one of the first to launch a dedicated ARM64 app.
Unlike traditional Intel and AMD processors, ARM's architecture has largely been synonymous with mobile devices and tablets, which are often powered by Qualcomm's Snapdragon processors. Microsoft's more recent developments have paved the way for proper ARM architecture within PCs, and promise a whole host of benefits including better affordability, permanent online connection and improved battery preservation.
With a popular free app like VLC making the first move, it's highly probable that other app developers will be encouraged to follow in its footsteps. You can download VLC as you normally would -- via the official website -- just ensure you select the ARM 64 version from the drop down menu.
Source: https://www.engadget.com/2018/06/01/vlc-one-of-first-arm64-windows-apps/
(Score: 3, Informative) by frojack on Sunday June 03 2018, @09:42PM (13 children)
Couldn't be any worse than the Crash-A-Minute SUSE Linus Enterprise ARM-Version.
Seriously, I haven't had a core dump in any version of Linux in so long, I've forgotten how to deal with them. Then SLES-ARM comes along (supposidly their Flagship payware product recompiled for ARM) and you seriously can't expect it to survive two days.
No, you are mistaken. I've always had this sig.
(Score: 4, Interesting) by Anonymous Coward on Sunday June 03 2018, @10:10PM (12 children)
You seen, programmers like to think that they've written something relatively high-level, but they haven't. In the case of C/C++, they've invariably written code that invokes "undefined behavior", which behaves a certain way on x86+GCC, but behaves another way on ARM+LLVM, or whatevs.
The situation isn't helped by the fact that ARM did what was expedient according to the MBAs: Creates SoCs as a conglomeration of proprietary parts, which necessitate proprietary blobs whose authors don't give a flying fuck about making something correctly, because they'll help paying OEMs work around any bugs.
The result for the ARM ecosystem is crappy software built on top of crappy binary blobs built on top of crappy hardware.
It's crap all the way down.
(Score: 3, Informative) by Anonymous Coward on Sunday June 03 2018, @11:28PM (11 children)
This is not too far off. I have coded for lots of different CPU archs. x86 is by far the most forgiving. ARM is *not*. If you use something wrong on the wrong frame/boundary/un-owned, it eats itself PDQ. Then add to that most compilers are not exactly great under ARM. They are wildly better than when I last used those platforms. But I always would port something to ARM to find all of the little squirrely bits in a bit of C/C++ code. Pretty much every time it would find something I did wrong. Then layered on top of these platforms is a set of documentation that is to put it mildly, poor. Then as you port between these different CRT stacks they all have slightly different ways of doing things. Even for something simple like printf.
(Score: 2, Disagree) by frojack on Monday June 04 2018, @12:02AM (5 children)
Once again, you've mistaken your hammer for the proper tool, because it was the only tool in your toolbox.
https://queue.acm.org/detail.cfm?id=3212479 [acm.org]
No, you are mistaken. I've always had this sig.
(Score: 0) by Anonymous Coward on Monday June 04 2018, @12:06AM (2 children)
Uh not sure what your point is? C can be unsafe? Sure. However, *when* I did this sort of thing the entire stack/memory/nvram was usually around 64k. You are not going to run much of an interpreted lang in that can do real time sort of things. I have used SoC python stacks and BASIC and others. They suck in perf if you have enough memory left over your program and data. But good luck with your use case!
(Score: 2) by FatPhil on Monday June 04 2018, @11:02AM (1 child)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 0) by Anonymous Coward on Monday June 04 2018, @10:24PM
It also has crap perf. It does not fit my use model. Do you think Lua fits in a few k with room leftover to do other things?
(Score: 2) by FatPhil on Monday June 04 2018, @10:49AM (1 child)
e.g. "C code provides a mostly serial abstract machine (until C11, an entirely serial machine if nonstandard vendor extensions were excluded)."
Complete and utter garbage. See all the endless discussions about sequence points over the decades for proof that much of what's expressed in the language does not need to occur in any particular order, and therefore implicitly, may happen in parallel if the architecture supports that.
e.g. "processors wishing to keep their execution units busy running C code rely on ILP (instruction-level parallelism). They inspect adjacent operations and issue independent ones in parallel."
Roughly translated as "I've never heard of VLIW and static scheduling". Or "I've never heard of HPPA, Itanium, and various DSPs, and definitely haven't encountered The Mill architecture, despite it having the theoretical highest ILP of any architecture ever designed". He should get out more.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 0) by Anonymous Coward on Monday June 04 2018, @04:22PM
The intersection is expressed with "and"; the union is expressed with "or".
"I've never heard of VLIW or static scheduling"
"I've never heard of HPPA, Itanium, or various DSPs, and…"
(Score: 2) by Subsentient on Monday June 04 2018, @06:26AM (4 children)
See, this kind of thing is exactly why I try to adhere to well-defined behavior as defined in the language standard documents.
Otherwise, you'll see this constantly. I remember a bug in xfce4-taskmanager on 32-bit PowerPC that I submitted a patch for, and it was literally someone relying on undefined behavior. I see it too much.
It's alright, I guess, to use extensions that are supported in both of the big two FOSS compilers (gcc and clang), but don't rely on undefined behavior otherwise!
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 3, Interesting) by FatPhil on Monday June 04 2018, @10:57AM (3 children)
I know, as a mathematician, what happens when I right shift an unsigned value by a shift as large or larger than the value's width - it becomes 0. Not in C, though, as some architectures interpret >>n as >>(n%width) by default, and forcing the compiler writer to know what the architecture would do and add additional code if the arch doesn't do the right thing would be too much hassle.
So people who inadvertantly write >>n without checking that n is in range are the victims of an inhumane language. Some indeed might rely on the value becoming 0 at over-large shifts. Yes, they're wrong, but they're justified if they then want to complain about the language being braindead. No idea if that was the UB you encountered, but IME it's a very common one.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 0) by Anonymous Coward on Monday June 04 2018, @05:47PM (1 child)
If the above is any indication of the state of SW development or the prowess of SW developers, then I'm not surprised that "most software is total shite".
If something is said to be undefined in the standard it is probably (I'm guessing here) going to be undefined in some or all implementations. It is undefined. I don't see how programmers can feel victimized if they fail to account for this.
Compiler writers pretty well must know the architecture in order to write an effective compiler for the architecture. I'm not sure how they could any other way.
(Score: 0) by Anonymous Coward on Monday June 04 2018, @10:24PM
The compiler won't check for overflow; that is left to the programmer.
However, because most software is written for x86, most programmers think that an overflowing right-shift is no problem, and that it will just produce the value "0". But, that's not actually what the C code means; the C code just means "issue a right-shift by the given number of bits". Hence, when said software is ported from x86 to some other architectuer, a subtle bug could creep in: The new arch doesn't allow overflowing a right-shift, or it shifts in crap instead of zeros, or who knows what!
Put another way: The standard is written so as to shift the knowledge of the underlying architecture from the writer of a compiler to the writer of C code. Well, that's what the OP says, anyway; I'm not sure how true that is in this case.
(Score: 2) by Subsentient on Tuesday June 05 2018, @04:36AM
You miss the point entirely. It's not about whether it was a good idea to add such and such to the language, or leave such and such as undefined behavior, it's about preventing architecture specific bugs in your code from not following the language standard.
If the standard says that whatever is well-defined behavior, listen to it. If it says it's undefined or unspecified behavior, listen to it.
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti