Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re: Basic (Score 2) 629

ACK Basic on a TRS-80. Wasn't very long before that was swept away by Z80 assembly language though. I remember magazines of the day containing articles that included listings (can't remember if it was asm or hex) that I would diligently enter. And then debug. I don't think that reading hex opcodes is something that the youft still get to experience, more's the pity.

Javascript is OK. It's a bit like lisp in sheep's clothing, and that goes all the way back to the beginning.

Highschool was only more Basic I think. University started with a local dialect of Object-Pascal and a little Fortran. C came later.

I don't think that there is enough emphasis on assembly language these days. By by the time I had graduated I had used assembly for Z-80 and 8085, 68000, NS16032, VAX, PDP-11. Maybe early SPARC. Perhaps TI DSP32010. One machine that I built myself for a project. Probably 8086 and 80286. ARMv2.

Lisp and its decendents (everything that uses garbage collection) are OK for theory and explorartory programming. Practice is important though. You have to understand what things cost, and why.

Comment Re: In other words... (Score 3, Insightful) 359

a) 64 bit processors can do 64-bit arithmetic in a single cycle.
b) The 64-bit processors in question have more named registers (fewer stack spills), and a significantly more efficient function calling convention (ABI)
c) 64-bit ABI doesn't touch the old x87 register set, which is another net performance win. (Not that VS2015 will use this much.)
Ergo: most of the time they are faster.
The only way to make a 64-bit program slower than a 32-bit one is to have enough pointer-chasing and associated irregular dynamic data that the change in pointer size materially affects the data cache miss rate. Certainly there is some code like that: VS2015 might even be an example.

How fast do you need your IDE to be though, and how much is performance really the instruction set's fault? Versions of Visual Studio have been produced that run in everything from .NET to JavaScript, and that's fair because most of the cycles are going to be consumed in GUI and file stacks anyway. Native code performance is hardly going to be the issue.

The issue is almost certainly that LLP64 is a dumb idea, and the code base will have lots and lots of pieces of historical code that assume that you can manipulate pointers with long arithmetic, and all of those are going to have to be found and fixed by hand, often involving real understanding and design decisions.

Comment Re:tl;dr; (Score 3, Interesting) 102

Only people who don't actually use processors at the instruction set level are uncertain about whether or not a processor is "32 bit" or "64 bit". If you look at the architecture, it is usually very easily apparent. Not always, but usually.

Does it take more than one instruction to shift a 64-bit value? It probably isn't a 64-bit processor.

Comment Re:Supplant 32-bit ABI (Score 1) 262


With a slight caveat that in that last one percent is probably the use case of DOM inside a browser page looks sufficiently like an irreducible thicket of tiny objects, and still wants all the speed that it can get, which is why Google is pushing x32 for Chrome plugins. Maybe it helps a bit for Javascript compilation too.

At least if your x32 is (a) sandboxed in a browser process and (b) generated by a JIT then the library duplication badness should be negligible and the result mostly invisible to the user.

For my own code, I wouldn't touch it with a bargepole. Storing pointers in memory? Madness...

Comment Re:Then make gestures with the keyboard (Score 1) 414

You've seen a lot of applications that work like that?

Sure it might be feasible. Might even happen, one day. Isn't the case now though, and I think that you're radically under-estimating the amount of re-work (basically re-design) that would be required to have fully-useful two-mode applications.

There are some, I suppose. Apple's got versions of Pages and their other iWork applications that run in desktop and tablet mode. So they're probably ahead of the game as far as useful convergence is concerned.

Comment Re: But unlike Android apps (Score 2) 107

Old school apps, the programs we used to run on PCs automatically had access to everything that the user who ran it had access to. And that didn't seem to be a problem. People would report "spyware" and programs that did badness would be shunned.

It seems that the fine grain permission protections of the mobile platforms have the inverse effect to the seeming intention: permission explicitly granted is exploited ruthlessly. And that seems to still be OK.

Comment Re:Windows 8 rocks (Score 1) 965

How can a task manager be "mind blowingly awesome"? Having to use a task manager at all is a fairly sure sign that things are not going well. That they've made that some sort of central feature is, IMO, a bit worrying.

Similarly: I've never used a platform other than windows where the act of copying or moving files around in the filesystem was so painful, or where there could be a reasonable cause to pretty up the dialog enough that you'd notice it. Everywhere else moves are normally instantaneous (unless to other filesystems) and copies are just copies. Yes, I am not a fan of MacOS asking whether you want to overwrite target files either: Unix had this right in the first place: unless it's locked down, in which case the action is failed, if I say I want to copy that over there, then that's what I want to happen. If I make a mistake I can jolly well recover from backup, or run around screaming.

Comment Re:What doesn't work? (Score 1) 965

I switched to MacOS from FreeBSD a few years ago because using appropriate proprietary graphics drivers weren't an issue (and always will be an issue on FreeBSD, as far as I can see), and because I wanted to use Lightroom for my photography hobby. That's all, but they're two things that I can't see changing any time soon. Switching to windows wouldn't have worked, because although I want those two specific features, I don't want to lose my comfy BSD/Posix command line environment. The windows command line experience has been astonishingly awful for its entire existence, so it is not something I can expect to change any time soon. I don't think that Ubuntu is in a measurably different position to FreeBSD in this.

Comment Re:Could you tell me more about the iOS-ification? (Score 1) 965

Most of the whinging seems to centre around the existence of an app-store (which, as someone who uses FreeBSD ports and apt-get on a regular basis is simply a good idea, not something to be afraid of) and the (optional) removal of permanently-visible scroll-bars in favour of multi-touch swiping on the track-pad (or mouse-wheel, I suppose.) I count both of them improvements, but clearly tastes differ.

Real iOS-ification would be sandboxing applications so that they can't operate on arbitrary files in the file system, and removal of access to said file-system. I can't really see either of those happening.

Personally, I can see where the tea-leaves are pointing, and am in the progress of moving all of my daily activity into a personal "cloud" hosted on my own FreeBSD box. Then I can use osx or android or whatever has the good proprietary graphics stack at the time and just get on with it.

Comment Re:Intel always rules high performance computing (Score 1) 605

I think that you'll find that a fair chunk of the top-end of the top500 (and the graph500) are IBM Blue-something systems that run variants of Power. These are essentially descendants of the PowerPC440 series of embedded processors: not terribly fierce on their own, but have a significant advantage for this sort of work: they don't consume much power. So you can run a *lot* of them with a limited power budget. Much like ARM, which is why several folk, including AMD, are lining up to do server versions of AArch64.

Which is why Facebook and others have created the Open Server Aliance, and why Intel, AMD and ARM are all members, and are all producing CPU+memory modules to suit that space.

Low power devices are the present and the future, even if you need the power supply of a medium-sized town to run the data-centre.

Comment Re:Isn't it time to trim FAT? (Score 1) 272

The patents and the compatibility in question relate specifically to the way Microsoft encoded the long-file-name compatibility, and the short-form-contraction extensions into the FAT directory structure. It's an ugly hack that no-one with skill in the art would think of doing, so it's a legitimate patent. I don't know why camera makers don't just limit themselves to the 8.3 filename space and avoid even dealing with long file names: every camera I know of seems to work like that anyway.

The primary work-around du-jour (and it's a good one) is USB-PTP protocol (and variants) that avoid the question by not exposing the block device structure at all: operate more like a network file system. Makes perfect sense. This is why lots of mobile devices don't have SD card slots. Add an SD card slot and you have to support FAT or exFAT. Leave the slot out and you can run ext2 or whatever on your internal flash drive, and expose files to the external world over wifi or USB-PTP.

Since the controllers in SD cards are computers too, it would probably be feasible to build some sort of SD card variant that spoke PTP directly, but how likely is that?

Comment Native framework not-quite-C++ yay. (Score 2) 37

I read a little of the on-line doco, and noticed that the "native development" system supports C++ but not exceptions. So two-phase object initialisation is a requirement and try/except is out, and a bunch of standard APIs can't be used. There was also something about restrictions on C use, should you prefer that, but also missing some standard library functions. That's not too surprising, but I suspect that the C++ restriction is going to make porting code from existing sources painful. I dimly remember C++ under Symbian being odd, for similar reasons. Maybe for exactly the same reasons and with the same heritage?

Comment Re:Underlying structure versus pretty pictures. (Score 1) 320

NeXT wasn't the only, or even the first OS that had vector graphics baked in at a low level. Acorn's RiscOS was all vector graphics and scalable, anti-aliased fonts from the late '80s on, on a 4MHz processor that had no cache and a dumb frame buffer in bandwidth-sucking "shared DRAM". True, it didn't have much in the way of actual resolution either, but it did work very well. Performance of the vector drawing primitives was never a big issue. That was a machine that was in the same ballpark as the IBM PC-XT (which was a contemporary), price-wise.

Comment Re:I can see it. (Score 1) 66

That's not it at all: tablets are now (or will be soon) just "screens": no different from the one in your lounge room or on front of the fridge. The circuits are just moving around a bit. If you want to *do* something with it, you'll be able to use that box with the hard drives and the peripherals sitting in the corner of your office just as easily as you can now, or you can rent space on someone's cloud server, if you prefer.

Don't think of it as losing your PC. It's more the case that your laptop/desktop monitor can still do a range of useful things after the "PC" has been powered down. There are already plenty of manufacturers who have the clue, and are selling WiFi enabled network hard drives: "personal cloud" systems.

Slashdot Top Deals

The IBM purchase of ROLM gives new meaning to the term "twisted pair". -- Howard Anderson, "Yankee Group"