My wife and I were talking about what lamps we had that were LED vs fluorescent vs incandescent; one of the bulbs that we have that is of the latter is in our closet, and has been there since before we bought the house in 2002 (the house was built in 1973).
18 years now, maybe longer, but it still turns on and has yet to burn out. Of course, we don't use it much, and it's only something like 30 watts (clear bulb).
To clarify, you don't usually see just "a" for an accumulator, as there are usually more than one accumulator-style registers in a CPU, and in many cases they are split along byte (possibly word) boundaries.
So you end up with accumulators called "A" and "B", but are composed of registers "AX" and "AY", and "BX" and "BY", with each being one byte (or word) wide; X and Y being high and low bytes/words of the register (and dependent on "endian-ess" too).
Sometimes you even get where multiple registers can be referenced by a singular name - "D" is a popular choice, and may be made up of "A" and "B" (being low/high "registers" of the larger word). IIRC, the 6809 was like this (?) - A and B were 16 bit registers, but could be referenced as a 32-bit word "D" (or maybe I am thing of the 68k or some other architecture - it's been a long while).
The only other time I have ever seen singular letters used for registers in assembly was for very old pre-microcomputer systems (beasts like the Univac and System/360 - though I think the PDP-8 had similar style). Also some of the very early "microcontrollers" (which were more like glorified sequencers with some extra memory and rudimentary branching, if any) had similar "registers" (Radio Shack once sold, as a part of their "Science Fair" electronic kits, a "Microcomputer Trainer" that was something like a very small 4-bit microcontroller with 128 bytes of memory or something like that - to teach assembler and a bit of hardware interfacing - it had "small" registers like that referred to in single letters).
The 8080 had A, B, C, D, E, H and L. These mostly carried over to the 8085. Newer chips have ax/al/ah, eax, rax type names the grew out of the original names. The Zilog Z80 and Sharp LR35902 were mostly 8080 compatible.
The MOS 6502 has, as gmfawcett said, single-letter names. These in turn carried over to Western Design Center (WDC)'s 65C816. There are actually separate instructions for loading and storing in A, X, Y and Z at least on the '816. LDX, STX, and so on. This means the Ricoh 2A03, Ricoh 5A22, Hitachi 6309, MOS 8501, MOS 8502, and the later MOS 65xx series and the CSG chips. A fun fact is that the 6502 had especially fast access to its zero page memory and special instructions for some functions on that page, the first 256 bytes of RAM. Language implementers sometimes made up for the dearth of registers by treating certain addresses in the zero page as additional registers.
The Motorola 6800 had two accumulators, A and B. The stack pointer was merely S. X is the index register. It also treats the zero page specially. The 68000 series broke with this, having eight address registers a0-a7 and eight data registers d0-d7.
All of the above used A as an accumulator at least by convention in the materials.
SP is the literal name of the stack pointer on x86 in 16-bit mode. It's also used as an alias for R13 in at least some Arm (AArch32 on v7 and earlier for example). SP and PC are the stack pointer and program counter on the PDP-11. It's aliased to r1 on the Intel 80960 (i960) since that is the stack pointer on that platform.
The PDP-8 used similar zero-page tricks to the MOS 6502, only given that it had one (1 !!!) register, that was necessary.
All of these processors where CPUs for commercially successful systems. They might "only" be microcontrollers today.
The MOS 6502 / 6510 and its variant the WDC 65C816 was in the Commodore 64, Commodore PET, the Vic-20, the Apple II, the Atari 2600, the Atari 400/800/600XL/800XL/1200XL/800XE/65XE/130XE, Nintendo Famicom, SuperFamicom, the NES, the SuperNES, BBC Micro, Ohio Scientific Challenger 4, Atari Lynx, Apple III, Apple IIgs, Acorn Atom, Acorn Electron, Franklin Ace, and loads of clones.
The Z80 was in most Amstrad models, in the original TRS-80, the MSX standard, VTech Laser, Intercompex Hobbit, Mattel Aquarius, the Microbee, the NEC PC-6000 & PC-8800 series, Sinclair ZX line & Timex Sinclair, Coleco Adam, and again a bunch of clones.
The Motorola 6809 was in the Tandy Color Computer, while the smaller CoCo MC-10 used the 6803. A few other companies built around this chip family, too.
The Commodore 128 featured both a 6500 series processor and a Z80.
Several of these processors still have versions produced in 2020, although they're not for your main desktop or your phone. Several of them are targets for emulation or new hobbyist software due to the popularity of their platforms. And yes, some of them are used as microcontrollers. Microcontrollers need code written for them, too.
I used Corona around that time - and from what I recall, projects did build locally; the only exception being that if you wanted to build an iOS version, you had to do so on a Mac with XCode installed. I also recall having to set up the Android dev environment in order to build for Android. I know that later they had where you could build on their servers, but what I recall (and I admit, it's been a while), local building was there back then.
This is kinda sad to see. It's been almost a decade since I last used Corona (then, it was called Ansca Corona), and I found it fun and exciting to use. My employer at the time wanted to use it to build a game app, and I spent a while messing around with it, learning Lua on the fly, and in general having fun making a "game".
I found the system to be easy to use, and relatively high performance. The only thing that was an issue - at the time - was something very strange, which kinda impacted another app we were building:
Corona had a map component, for google maps - but for some reason, it wouldn't work for Android - only for iOS! So - you could create an app with that component, but if you compiled it to install on Android, it would fail, but you could compile it for iOS and load it on an iphone and it would work fine.
At the time, we had an app idea from a client that we wanted to use Corona for, but because it needed mapping, and that didn't work, we were forced to go with another option (PhoneGap and Bootstrap Mobile), that wasn't nearly as performant - but we could embed a google map easily.
Contact with Corona revealed they were working on a fix to get the map component to work with Android, but it came too late for our purposes (and actually didn't happen until about a year or so after I had left that position and had moved on).
Anyhow - I'm glad that the system will live on, although today there are a ton of other options available for easy cross-platform mobile development. Still, I haven't found anything that worked quite as well as Corona.
Gotta say thank you for this resource; I'm always using bash for one thing or another, and this will be a helpful site for the future. I've got it bookmarked for just that reason!
Years after I worked for the company I mentioned before (building an in-house VB6-based ERP system), I worked for another web applications development company who had a client I was "assigned to" to develop software for healthcare management and billing, etc.
It was all web-based - we even had a version for "mobile" (at the time which meant a ipaq personal assistant, running a version of Windows CE and a browser that made IE6 look sane).
The idea behind it was "patient-centricity"; the patient could manage, view, and "edit" their own healthcare records, and any physician on the system could have access to that patient's records (the patient would have to give approval to share with the provider).
It wasn't ever going to replace EPIC or any of the other large medical record systems, but the fact that a patient could control their own data was a significant part of the core marketing behind it - provided you could get other providers and support people on-board.
Things were going rather smoothly (but not very quickly) in the progress of the development of this app, until the client wanted to make the entire thing HIPAA compliant. At the time, this meant taking it off our in-house shared hosting environment, and get it on something else. What we found was, at the time the only option was to lease a full rack from Rackspace and use their services (and servers), as they were (supposedly) fully HIPAA compliant.
The client balked at the cost to implement such a system, and instead opted to roll their own. Then the client decided to hire their own developer (without telling us), and wanted us to backdate some HIPAA "compliancy documents" to say their system was fully compliant on a date when it wasn't. My employer thankfully decided not to go down that road, and instead to drop the client and contract (probably the best decision he ever made).
I once worked for a company that let me go because I looked bad on their bottom line and they were looking to sell the company, around 2003. So, severance package in hand, and one week later I had a new position at another company making much more than I was originally.
Anyhow - I was essentially the sole developer of a simple ERP system written in VB6 and using an Access 2003 MDB file for storage. It was being used in-house by most of the company at that point, from billing, to shipping software and patches, to other reporting, CRM, etc. I looked bad to the bottom line because my salary was going entirely into this in-house developed product, that was producing no revenue for the company. I was a literal cost center; I don't blame them for letting me go - it was probably a good business decision...
When I was let go, I was trying to transition to postgresql for the backend (away from the MDB file), and hopefully move the frontend away from VB6 - and make the whole thing a web application in some manner.
They told me when I was let go they told me they were looking into other options to replace the software I had almost single-handedly written to manage the business.
So - I was let go, and the business was sold. Twice. Today, it's part of HP, last I was aware - about 3 years ago. That was about the time that I had to look for a new job, and talked to my former supervisor there (he'd since become VP of his department).
Yep - still using the same old software, with virtually no updates or fixes. Still running on the MDB file. And somehow, it was still all working, nearly 15 years later. I'm amazed, impressed, shocked, and also in complete wonderment how it hasn't fallen over hard since then.
As far as I know - they are still using it. I've been told that both the original company that bought them, then HP (after they bought that company), both looked at the software and wanted to monetize it - everyone who's seen it has been fairly impressed with it, from what I understand. But, because it's so tightly integrated with the business, plus that it was never designed to be modular and salable, has meant that without a major refactor, it can't be easily done.
Honestly, I'm glad it can't - I'd do so many things differently today that I didn't do then (and if done, they could probably sell it as well); it's the kind of code that I know some developer will look at, then want to track me down for a good ol' fashioned murdering - or at least to beat me with a baseball bat.
That must be the magic of Windows in action. Software still running after 15 years.
I have to do some maintenance or decommissioning of very old apps in an old bank. I find anything Linux and C or C++ related is the worst, because the system libraries themselves are unstable. Applications fail because of .so dependencies breaking, both system libraries and application libraries (themselves forming a tree of dependencies). It can be extremely hard to rebuild and relink the software with the whole chain of dependencies for the current platform.
Linux executables die along major OS releases every few years, but Windows binaries can keep working for more than a decade easily.
It's possible to make statically linked applications but it's pretty much never done.
And it's against the linux packaging mantra, where you should be able to "apt-get install libqt" for example (noting that libqt package is completely detached from the release cycle of your application).
This leads to a ton of accidental dependencies and they're tied to the OS release. Even the simplest of apps might eventually depend on libc, pcre, openssl, etc...
Windows is simply different on this aspect. It's more friendly to static builds and the system libraries are more stable. If you built against some win32 API or the Visual Studio 2005 SDK, the DLL are still present and working.
Even in the dotnet era, you have WinSxS and exe/dll specific manifests pinning specific library artifacts with apps and a loader that keeps a repository of every version referred to on the system. The linux/ELF ecosystem on the otherhand decided to try to implement various degrees of semantic library versioning, with differing (often poor) degrees of success.
When your target is a system image thats rebuilt entirely from source you can get away with the latter somewhat more easily, but its definitely no panacea. Just look at OpenSSL. (libmemcache is another personal 'favorite' of mine.)
It's why MS tried to push the British gov to accept their shitty ODF format rather than a proper one.
Because they wanted backwards compatibility with their modern and stoneage office suite versions with their own quirks and issues.
They're obsessed with backwards compatibility and it has it's own issues.
Microsoft Office's native format is OOXML (Office Open XML). The ODF (OpenDocument Format) is the native format of LibreOffice, and the UK decided to go with this one (despite Microsoft's lobbying).
Great story, I don't want to know the number of companies that run business critical stuff on excel vba macros + access DB some guy wrote 15 years ago.
SAP is a company (and software system) that exists to buy up other company's software, business, and services and then integrate that all into SAP's "core" systems, and do so in such a poor manner that their name and the system has almost become synonymous with the words and phrases "nasty", "unreliable", "run away now", "if you know what's good for ya" and a host of others.
However, due to their entrenchment in various other markets (and who knows if there is any graft or other under-the-table business going on), they continue to manage to exist, and scary enough sell their products to new victims (ahem - customers).
SAP is the old-is-new-again-we're-IBM type of business; nobody ever got fired for buying SAP (but the golden parachute was nice)?
Ok - hyperbole and I don't really know what I'm talking about, so the above should probably be ignored...
...that said - I don't think I'm too far off, either.
Yeah - I'm not mathematically inclined enough to understand what would be so funny about the 38x^3 denominator either?
Unless it's something that would cause an error due to memory/register size constraints, or cause the calculator to sit there forever on some of the other larger squares or test values due to 1986 speed of the ALU or whatever is in the calc?
My gut assumption is that it's some mathematics inside joke of some sort...
> The industry as a whole used to be more aligned with engineering but this has changed considerably since, say, the rise of "Agile".
I'd argue that it changed once smaller businesses could afford (and have room for) their own computer. My best guess would be somewhere around the PDP-8 era (late 1960s-early 1970s).
Once things started to move away from large-scale computer rooms and consoles of blinking lights, towards a more "hands-on" and interactive approach, where the programmer didn't have to wait between "batches" of runs to see what their code did (correct or not), that is when (from a software development point of view) so-called "engineering" went out the window.
18 years now, maybe longer, but it still turns on and has yet to burn out. Of course, we don't use it much, and it's only something like 30 watts (clear bulb).
Someday, maybe, it'll get replaced.