It doesn't have to be the NULL macro, which is correctly defined as plain 0.
The literal 0 is treated specially, so this could indeed be one of those 'turns into a weird bit pattern NULL pointers', if such a thing existed in the wild anymore.
But you're correct in that there probably haven't been any since the turn of the century or whenever the last Univac mainframes got turned off.
Apparently according to the c-faqs link elsethread
execl takes a variable-length, null-pointer-terminated list of character pointer arguments, and is correctly called like this:
execl("/bin/sh", "sh", "-c", "date", (char *)0);
Due to ececl being a variadic function it can not take advantage of a prototype to instruct the compiler that one of its arguments needs to be treated as a pointer context.
Depends on the country. In the UK, the Amstrad 8256 and 8512 were very popular, and they were only launched in 1985. They were much cheaper than PCs of the time, and came with wordprocessor package and CP/M 3.0. We had about 25 of them in our lab, including one floating at 4000V in a perspex cage, used to control a C14 accelerator.
From memory, I used TP and them TM2 on CP/M to run an automated thermoluminescence rig, then FTL Modula 2. I wasn't very professional at the time, but then no-one was - most of us were working in isolation. Speaking from that perspective, I was not very impressed with Modula 2. The issue was not with the fundamentals, but the way that it was case sensitive and forced you to use caps for all the keywords, so that it was really annoying to type. As a lesser issue, the names used for type conversions between numeric types seemed to have no rationale, so they were easy to forget. I don't remember exceptions in TM2, and they would not have been part of the standard language. They appear to have come in with Modula-2+.
They were very nice machines. I wrote my first useful programs on these using Mallard Basic to help with my school work. The word processor was really powerful too. I would have turned in my schoolwork using this too but that was unheard of at the time.
There were a couple of Modula-2 vendors for MS-DOS and Amiga. It was TP on MS-DOS, Object Pascal on Mac OS and stuff like BASIC compilers on the Amiga side that made them lose market share.
They probably reused a lot of ideas in Turbo Pascal 4.0. It had units which were very similar to Modula 2 modules, except that interface and implementation were in a single file.
Most of those ideas come from USCD Pascal, and the later Object Pascal introduced in Turbo Pascal 5.5 came from Apple's Object Pascal, which was derived from Clascal and developed in collaboration with Wirth.
Probably, but there were many other language differences in Modula-2 that made it a better language. I suspect the real reason was the usual one: inertia. A lot more people knew Pascal and thus more bought TP than TM2. <something something about technical merit and popularity contests>
There are a few options that let you use RNNoise. (I posted another comment a bit further up on how to pipe your audio through OBS to implement this. There are undoubtedly simpler options.)
In my experience, it does a great job cancelling out keyboard clicks and clacks. Even if I sit here and slam on my spacebar harder than I'd ever hit it even writing an angry email, it's cancelling it all. And I've never had an issue with it _not_ picking up my voice.
If you're just looking for _a_ solution to the problem, I'd give something with RNNoise a try.
I actually tried writing a version of this for windows just an hour before this was written. Usually when I do this I find there is one already just as I finish it, but if not then I’ll put it on GitHub within a week. Will post another msg here if I do.
The DasKeyboard Brings Back the Feel of an IBM Selectrichttps://www.pcworld.com/article/251792/the_daskeyboard_bring...
"If you remember what it was like to type on an old IBM Selectric typewriter, you know about what the experience of typing on the DasKeyboard ($129) is like. The company actually had a couple of old IBM Selectric typewriters at their booth."
Daskeyboard, like most mechanical keyboard makers, uses plastic cherry mx keyswitches or the generic chinese cherry clones. Those will feel nothing remotely like either a selectric or a good mechanical keyboard such as a model F/M. The person who wrote that article has no idea what he's talking about.
I read that the Model F keyboard were supposed to emulate the feel of the Selectric keyboard. Haven't bought one before, but heard a lot about these: https://www.modelfkeyboards.com/store/
My mother also had a Selectric, and I used it sometimes. I mostly remember it being loud.
I don't recall the keyboards being especially different, but I was just a kid. I do know that it utterly spoiled me for dome keyboards, which I always hated; I hauled that Model F around for about fifteen years, before going full-laptop for awhile. I still have it.
At which point the mechanical keyboard renaissance was in full swing, so I use an Ergodox now. Cherry-type switches are good enough, but if someone made an Ergodox type board with Model F type buckling spring keys (fat chance), I'd have my grail.
Between the Selectric and the Model F was another IBM keyswitch design known variously as the "Beam Spring" or "Keyboard B" which was much closer to the Selectric in feel. It even used the same keycaps as the Selectric. The Model F was introduced as easier to manufacture and more compact.
If money is no object, the closest you can get is a "Beamspring" board from a '70s IBM terminal.
There are adapters you can bolt on to make them speak USB, but a lot of them are a significant effort of cleaning/derusting/repairing since many of them are "barn finds" in iffy condition. A nicely restored one will be in the 1-2k range.
I wonder if an alternative would be to take an actual Selectric, which are likely cheaper and more available, and tap into some part of the mechanism that parses the keystrokes and convert that to modern signaling. I could imagine a comical assembly that's basically one of the old typeballs with a few dozen contact switches, all wired to a Bluetooth keyboard module
Have to strongly disagree here... they were the best touch and feel for the typing speeds of those days, but that kind of touch would not be suitable for today’s 100+ wpm.
Time value of money, if you can deduct something in 2020 vs 2021 you get 1 year of interest on that deduction. Even if you don’t directly invest it, inflation make paying 2020 debts in 2021 dollars a net win.
However, a larger issue is percentage depletion makes it possible to write off more than the cost of the asset. If I buy something for X, then the sum of all of my depression should be X or less.
Accelerated Depreciation is a net win for companies. So, the shape of the curve is very much an issue worth considering.
Consider, a company buys and new car and the car’s resale value may tank the day they buy it. Further, companies regularly use things they which have a book value of zero.
An easy way to favour an industry is to allow them to write off assets faster than they're actually used up.
So while the amortization itself seems fair, many oil companies have lobbied for these types of changes, which together amount to hidden subsidies worth billions every year.
Why does accelerated depreciation help a company? (It helps that they pay less tax initially, because they can offset more revenue, but then they are left with less expenses to offset revenue later, how does it help them? Or again the explanation is time value of money?)
Also oil wells' production curve should match the depreciation curve, no? (You can extract more initially and it drops off, especially as the pressure lowers, you then have to inject extraction fluids, CO2 or brine or whatever, crack the surrounding rocks, and eventually it gets abandoned as a production well.)
Yeah, it's time value of money. There are many kinds of subsidies, including direct to consumer. If you're interested, the IEA's old reports mentioned here would be the best place to start (many countries have since cut their subsidies, so there's progress):
Z80 is quite OK with its real stack and the 16 bit registers. Almost exactly the same as the "small" (64 k data, 64 k instruction, IIRC) memory model in Borland C for DOS, which I used quite a lot back in the day. Only occasionally did my programs get large enough that I had to increase the memory model.
The 8086 you used with Borland C is far from orthogonal (orthgonaliry, together with a large register file is what makes a cpu compiler friendly) - but it is significantly more orthogonal than the Z80.
And even the 8086 wasn’t compiler friendly - in those days I would easily outdo the compiler by a few hundred percents in right loops. I no longer dabble in assembly, but from what I heard, ARMs and AMD64 have gone far enough (as did compilers) that people rarely beat compilers on them.
People still win on vectorized architectures (GPU, AVX) and I suspect that will stop only when the languages become more vector friendly.
I'm not saying the Z80 is a wonder for compiler construction. But it's decent enough for a C compiler. It has a stack spanning the full address range (up to 64k), so all auto variables can be easily allocated on the stack. Arguments are typically also pushed on the stack in C. So the number of registers is not as important to a naive C compiler as is a decent stack. Oh, and the last, you on the Z80 also have easy absolute and relative addressing to all addresses, so you can easily implement global and static variables.
It feels very much like coding for a modern machine, just instead of having a memory limit of 2 gigabytes of RAM or whatever (for a 32 bit CPU) you have a limit of 64 kilobytes. And the integers are 16 bit instead of 32 bit, but again, this was normal in DOS too.
So that is why I made the comparison, C in CP/M or whatever on the Z80 didn't feel that much different from Turbo C on DOS.
1. The 6502 is heavily register-starved. Three limited-purpose registers is pretty rough.
2. There are no 16-bit registers, so you can't put a pointer in a register. You can put one on the zero page, but that's much more limited. Indexing into arrays larger than 256 bytes gets complicated, too.
3. The 6502's stack isn't well suited for storing data. There's no SP-relative addressing, for instance. It's possible to get the value of SP with PHP/PLA, but this is pretty awkward to work with.
I wrote a self-hosting (if you're very patient) compiler for the 6502 and Z80 a while back. Both are a bit of a shock if you're used to true 16 bit arch architectures. I did a couple of writeups on the problems of doing basic arithmetic in them:
The 6502 is more orthogonal, and while each instruction does less they're very fast; the Z80 is fundamentally more powerful but weirdly inconsistent, terrifyingly slow, and the unorthogonal register system means that you spend half your time shuffling registers.
Re: pointers, the same problem applies to int, which was always at least 16 bits. The 6809 and 8080/Z80 had 16 bit register (or register pairs) so must have been much better targets for C (among 8 bit machines).
It has a 256 byte stack, no multiplication/division, and if you look at typical 6502 code, a lot of it tends to be self-modifying - e.g. modifying the location of the most-significant-byte of addresses to copy more than 256 byes for example. That's a reasonable-ish thing to do when you have tens of KB of RAM available and can easily keep track of everything that's going on. But it's not very C friendly. It's certainly possible, and there are multiple C compilers as well as compilers for other languages, but most of the machines it's used on are small enough that using assembler and some macros tends to be closer to the sweet spot.
There are a number of c compilers for 6502. They all produce bad code and/or stray quite far from c. Looking at the architecture sort of explains why. Things c needs, it makes hard to do (pointer math, reasonably sized stacks)
The literal 0 is treated specially, so this could indeed be one of those 'turns into a weird bit pattern NULL pointers', if such a thing existed in the wild anymore.
But you're correct in that there probably haven't been any since the turn of the century or whenever the last Univac mainframes got turned off.