> Less immediately visible to someone working at the assembly language level instead of the machine code one is that relative addressing is much more common on the 6809, meaning that it’s significantly more viable to write position-independent code on it than any of the other chips we’ve looked at here. Only the 8086 comes close, and it achieves it by using its segment registers as a de facto relocation base.
I would love to learn more about this. Does more "position-independent code" mean the linker has much less to do [0], or is there an actual difference in the code base for similar tasks?
In theory, the motivation for position independent code was to support the development and use of software libraries that could be "plugged in" to an application.
In practice, RAM was often limited to 16 KB; software reuse that I'm familiar with on a 6809 platform was at the source-code level and optimized by the programmer.
I remember editing and assembling, but not compiling or linking.
That said, I believe Motorola wrote some floating-point libraries.
I was a kid on a Tandy Color Computer, and the $49.95 EDTASM cartridge was a huge investment for our family. So my point of view could be way off... but the simplicity of the Color Computer with the design of the 6809 made programming delightful. (20 years later, my enjoyment in programming the Palm Pilot felt like that... although by then I could use C as a fancy macro assembler.)
Larger and later systems could use OS-9, which reasonably resembled UNIX and maybe supported a C compiler.
I believe that linking became important when programs got too big to compile within the memory limits of the computer. Then you had to compile portions of the code into separate object files, and then "link" those object files by reconciling the identifiers with their addresses. Without having to haul everything back into the compiler at once. It also meant that portions of a program didn't have to be recompiled if they weren't ever changed.
This wasn't the only way to skin the cat. Multi-pass compilers were another way.
Relocatable code could make more efficient use of memory, for instance not having to worry that your object code would end up crossing a page boundary after linkage.
Technically it wasn’t the linker that’s simplified, it’s the loader.
Modern systems don’t worry about PIC code, they have virtual memory so everyone sees memory the same. The virtual memory system manages the relocation automatically.
OS/9 relies pretty much entirely on PIC code, that made the loader and multi-tasking easy.
Original MacOS also relied on PIC. For similar reasons, and it’s partly why code segments were limited to 32k.
Then you have things like the original 8086. As long as you stick with the “tiny”/“small” memory models, everything was relative to the segment registers, so code and data could be moved easily.
In contrast you had systems like the Apple IIGS. The 65816 does not support PIC well, so code segments carry a relocation table that allows the segment loader to relocate code during transfer from disk. The creation of segment and relocation table is the job of the linker.
In general, yes, the linker (if there is one) would have less to do.
Position independent code (PIC) on the 6809 is pretty easy [1], but it does increase the code side a bit, but the resulting code can be placed anywhere in memory with no changes and still work. As mentioned, Motorola intended to sell a ROM with IEEE-754 floating point routines for the 6809 (as the MC6839) that was PIC. As far as I could tell, they never did sell the ROM, but they did provide it (with source) for anyone to use.
[1] Relative branches instead of absolute jumps, using the index registers to address memory, as well as addressing relative to the program counter. You can still do jump tables, but instead of a list of addresses, they're just a list of relative jump instructions. That type of thing.
On older hardware such as this it could e.g. let you write a multitasking environment that supported shared libraries without use of an MMU (though you'd hit memory constraints pretty quickly on a Z80-era cpu!).
I'm not familiar with the instruction sets of the 6809 but I could also see more compact opcodes, e.g. a JMP with a relative offset can be encoded smaller than JMP with an absolute address.
In modern terms PIC is used for ASLR and is therefore a security requirement. Some arches (I'm most familiar with arm64) are entirely designed around PIC and you need extra hoops to do anything in absolute terms.
In practice it just meant the “zero page” could be anywhere, not the 256 bytes starting at 0x00 (like the 6502 zero page). The opcodes that operate on zero page are shorter and thus faster.
In terms of "safety" this leak is a drop in the bucket. The greater concern would be that election systems are involved. If election information is unintentionally readable, it is also therefore potentially alterable.
It doesn't work that way -- it's not an open DB endpoint with misconfigured permissions, or something like that.
Up here there is a custom of sharing essentially a dump of the elector's table with every political party in the early days of an election.
This dump is seeded with some fake data before being released to a single political party, so if said party gets up to shenanigans, we know about it. These of course do nothing to prevent privacy violations, only to detect and punish them after the fact.
Personally I think this is a dated system from a bygone era, as there is obvious risk of permanent harm via election fraud in an environment where politics actors are highly motivated. If you believe Canada is an evil woke empire from which you must protect your sons, you will likely not care about Canadian electoral law.
Electorate data should be maintained by the political parties themselves, and guarded like nukes. New political parties should put in the hoofwork to build their own damn lists.
As far as I know Canada uses paper ballots and count the votes in front of witnesses at polling places. I doubt you can sabotage the system by just meddling electronic records.
Agreed, how HolyC serves as an inspiration could be clarified. Was it an aspect of HolyC? The background/context of the author's life, meaning Terry Davis was inspirational? Impossible to tell. Other resources [0] [1] don't mention this aspect.
> Be welcome to the exciting world of graphical C applications using SDL (Simple DirectMedia Layer). SDL, originally developed by Sam Lantinga in 1998...
This is what I've been wondering after only a cursory glance ("It...generates optimized C code" from the OP). Interesting that mruby itself got a major version update around the same time (in just the past few days) https://github.com/mruby/mruby/blob/master/doc/mruby4.0.md
It looks like magic because it works like magic. Surprisingly it is also possible to believe in the magic of "government intervention" though it looks less like magic and more like unintended consequences.
Doing nothing and letting the market do whatever is also full of unintended consequences. Your argument is like letting your yard go to weed and accumulate a bunch of knotweed and himalayan blackberry. Yeah you can argue that you didn’t do anything to create that situation but at the end of the day you’re still responsible for it.
The thing is that not doing anything is still a policy decision. Unless you want to go full bore libertarian there will always be regulation. By saying that the market is magic and the government is intervention, then you ignore all of the intervention exists already and just saying you are fine with it.
> The farm equipment industry spent 20 years adding complexity and cost. Ursa Ag is wagering that a significant number of farmers never wanted any of it.
Nice tag line but not a complete picture. The "significant number of farmers" in terms of actual market spend driving the equipment industry is not mom-and-pop outfits but rather agri-industrial complexes with machines to match. What they want is (1) availability and (2) ROI. For (1), that is first and foremost subject to legal stipulations like EPA etc, then secondly subject to production availability. For (2), electronics are the name of the game if you are looking to turn a profit with farming because counting every seed, measuring every drop of chem, and tracking every inch of plotted ground leads to better ROI.
Farming is a way of life for a lot of people, not just a business. That’s what is missing from your picture. And by population, small time farmers significantly outnumber industrial outfits, regardless of how much they spend. Sure you can make more money selling the most advanced tech to the biggest spenders. That doesn’t mean there isn’t a market for affordable, reliable equipment that gets the job done. Add on the risky nature of farming and its untenable to trap yourself in high 6 figures of debt and pray that you can optimize your way to enough profit to pay the interest.
Not so. In fact, farming is a way of life for almost nobody in developed countries.[1]
Ursa shows us that there is indeed a market for "simple and reliable" equipment -- but it's not cheap or affordable. There is zero market for "affordable" equipment, because almost nobody does small scale farming anymore
Small farms became economically and socially irrelevant almost a century ago in developed countries. Petroleum based fertilizer and industrial machinery drove the marginal cost of food to zero, and it is now only profitable to farm at very large industrial scale.
The main social outcome there was that starvation and malnutrition became vanishingly rare in these countries.
(In fact, _obesity_ is now, for the first time in human history, a widespread problem for the poorest in these societies.)
Society chose "nobody starving" as a better outcome than preserving romantic small farms for the sake of tradition.
Ah yes, millions of people = “almost nobody”. Do you also believe trans people are irrelevant because they make up less than 1% of the population? Let’s also ignore that plenty of people live on homesteads and do small scale agriculture for their own needs (eg feed for animals) while working other jobs. If all you have is statistics and you’ve never lived in the country, maybe you shouldn’t pretend to be an authority. But please go on and continue telling other people their lived experiences aren’t real. It’s sure to make you plenty of friends. This is exactly why a lot of normies hate tech people, extreme arrogance and a complete inability to see outside your bubble.
Fancy gains in ROI come from smart seeder/sprayer attachments and combine harvesters (a completely different piece of machinery), not from the tractor that's pulling those equipment. At best there's the ROI from less seed overlap, but plenty of GPS systems integrate well into any tractor and the gains are really marginal. I don't think tractor electronics are as important as they're hyped up to be.
> This is the story of OpenBSD on the Sharp Zaurus systems. Because of its length, I have decided to split it in two parts.
> OpenBSD/cats: the enabler
> OpenBSD/zaurus (to be published 20260513)
...I will be visiting again in 5 days. Then, I will be searching eBay for a Zaurus...
http://miod.online.fr/software/openbsd/stories/zaurus.html
reply