It's the thing people don't get when they see odd studies being funded and try to judge if they're worthy of being funded. Either it's just they don't understand where the study fits into a larger problem or simply that esoteric studies sometimes leads to surprising findings that are far more useful than anyone could reasonable predict.
At least that nominally creates some value at the end of the day. Documentation is the thing everyone wants but no one has time/desire to create. My most recent token heavy task was having an agent write unit tests for coverage on a little graphAPI tool I'd written a bit ago to satisfy SonarQube.
People don't want to read LLM-generated docs though. It'll lack the context to justify why things were designed the way they were, and there's always a risk of hallucination so you still have to verify the documentation's claims, since the person who published it likely did not scrutinize it.
There's two major types of documentation "why is this like this" documentation and then there's "here's the features of this library/tool" documentation. LLM stuff is fine for the latter as long as you screen it for hallucinations. Your right the former they can't really do because they don't have access to the reasoning but I've often found even the latter to be lacking in many teams.
...Yes. I didn't say fire and forget but it can handle a lot of rote recitation of library flags and functions perfectly well. The kind of stuff that's autogenerated with javadocs, inputs, outputs and effects that are all in the code are available to the LLMs. Like all things with LLMs generate and review but I've seen some good outputs with minimal errors that saved days of work no one was going to be given the time to do.
Why/when are traps used rather than explicit system calls? Is it just historical coevolution? Or is the idea that the user mode program doesn’t need to know that it’s unprivileged? Or is it just repurposing the error handler path to perform privileged operations?
Most processors support both "interrupts" (an external peripheral is banging on the CPU's interrupt pins... but also invocable from software; software interrupts; SWIs; INT instruction on x86) and "exceptions" (e.g. divide by zero, bus error, illegal instruction). Depending on the processor, accessing the "privileged" mode can be done either by software interrupts, exceptions, or both. An operating system should pick one and stick with it.
Other uses for interrupt/exception/trap vectors include hardware breakpoints: don't try and single-step the CPU, overwrite the code with an illegal instruction and control will flow to the illegal instruction handler where you can see all the registers then execute the real instruction that was meant to be there and return to where you left off. Some CPUs have a formal "BKPT" type instruction for that.
One other use on the 68000 is that any unrecognised instruction that started $Fxxx triggered the F-line handler; all the floating point instructions were in the form $Fxxx, so if you didn't have an FPU, you could put a software emulator for the FPU instructions in the F-line handler and software wouldn't know the difference. Traps/exceptions don't have to be a jump from unprivileged to privileged, they can just be utilitarian.
> Depending on the processor, accessing the "privileged" mode can be done either by software interrupts, exceptions, or both. An operating system should pick one and stick with it.
Practically most will support access via both, but for different reasons. For example, page faults (which the software cannot possibly predict) are going to be exception-mediated, but syscalls (which the software asks for) are triggered via an interrupt.
At the time of DOS, x86 didn't have multiple privileges. The system call instruction was typically INT, the software interrupt instruction.
Later on the 386 Intel added virtual 8086 mode which trapped to the kernel privileged instruction exception also for certain instructions that had to be virtualized, among them INT.
We used a set of INT instructions in well-known low memory addresses that all jumped to the same place. We had an ASM file that you linked with, that had sixteen different address combinations for each.
The common entry point would look back on the stack and calculate from the return address which entry point had been called, and run the appropriate kernel call. We called it the CS:IP hack.
In the context of this post, the DOS INT10 and INTx(I forget) required the caller to load registers with the desired system call number, then perform the trap instruction in their code. Fortunately CTOS didn't need those particular software interrupts, so I could implement them for my purposes.
Windows 95 used a related hack. Whenever a v8086 program asked to create a call to protected mode code ("please give me a real mode address to call to, in order to start executing the protected mode routine at address 0x123456"), Windows would store the entry point in a table and hand out real mode addresses like FFD0:0, FFCF:10, FFCE:20, FFCD:30, FFCC:40 that all point to the same instruction (because the segment part is shifted left by 4 in real or v8086 modes).
The routine at 0xFFD00 could then enter protected mode and use the code segment to build the index into a table of entry points: FFD0 goes to index 0, FFCF goes to index 1, and so on. But for extra kicks, the address isn't actually pointing to valid code. It points to a random "c" character in the BIOS, which is an ARPL instruction - which in turn is invalid in v8086 mode and therefore invokes the undefined opcode exception handler. The exception handler, which handily enough is already running in protected mode, then takes care of doing the 32-bit call.
> It so happens that on the 80386 chip of that era, the fastest way to get from V86-mode into kernel mode was to execute an invalid instruction! Consequently, Windows/386 used an invalid instruction as its syscall trap.
I also read this part but I wonder how did they benchmark back then?
> Schulman’s Unauthorized Windows 95 describes a particularly unhinged one: in the hypervisor of Windows/386 (and subsequently 386 Enhanced Mode in Windows 3.0 and 3.1, as well as the only available mode in 3.11, 95, 98, and Me), a driver could dynamically register upcalls for real-mode guests (within reason), all without either exerting control over the guest’s memory map or forcing the guest to do anything except a simple CALL to access it. The secret was that all the far addresses returned by the registration API referred to the exact same byte in memory, a protected-mode-only instruction whose attempted execution would trap into the hypervisor, and the trap handler would determine which upcall was meant by which of the redundant encodings was used.
And if that’s not unhinged enough for you: the boot code tried to locate the chosen instruction inside the firmware ROM, because that will have to be mapped into the guest memory map anyway. It did have a fallback if that did not work out, but it usually succeeded. This time, the secret (the knowledge of which will not make you happier, this is your final warning) is that the instruction chosen was ARPL, and the encoding of ARPL r/m16, AX starts with 63 hex, also known as the ASCII code of the lowercase letter C. The absolute madmen put the upcall entry point inside the BIOS copyright string.
(Incidentally, the ARPL instruction, “adjust requested privilege level”, is very specific to the 286’s weird don’t-call-it-capability-based segmented architecture... But it’s has a certain cunning to it, like CPU-enforced __user tagging of unprivileged addresses at runtime.)
Ahhh.. probably my first program. Don't forget the int 20 at the end! It was beeping great. Still never unlocked the mysteries of those TSR programs though.
It's been a long time since I've touched any of this, so the details have slipped my mind. However, the general idea was that there were two different exit calls in DOS: terminate and terminate and stay resident. The difference between the two is that the stay resident option wouldn't release the memory used by your application. Further, the interrupt table, which told the processor how to handle each interrupt, was in RAM and therefore writable.
So, what TSRs would do is overwrite one or more interrupts to point to a routine that would check if the system call in question was one it wanted to handle (eg, to add a hotkey it would grab the keyboard handler and check for a special set of keys before passing control back to the normal handler). Once that was fine, it would call the TSR system call and control would be passed back to the OS with the hook still in place
Still never unlocked the mysteries of those TSR programs though.
I made a bunch of those, in TurboPascal. Just needed to save registers (including stack and heap segments) and hook some key combination. One of them was used commercially for installations by a very big company.
Testing was a little prone to spectacular failures. But once the general procedure was debugged, it was easy as pie.
I don't know OG x86 (cuz, ewww) but on 68k this was generally the way. On my Atari ST a syscall was performed by filling your registers and stack as expected, then executing one of the TRAP opcodes and that would get the CPU To save PC etc & jump to the handler but in supervisor mode, where your syscall could then read state perform accordingly, and then return back to you.
I think x86_64 has just formalized this into a specific SYSCALL instruction?
ARM variants call it SVC (supervisor call).
Same difference.
Some older operating systems just implemented their syscalls as ordinary subroutine jumps, though, and everything ran in supervisor etc. I believe AmigaOS was like this, you just went through a jump table. Which, I think, shaves some cycles but also means compromises in terms of building for memory protection, etc.
Depends on the processor architecture and its nomenclature.
Traps typically also result from exceptional conditions (like divide by zero or page fault).
An architecture may or may not provide non-trap paths for less-privileged code to invoke more-privileged subsystems (call gates, "syscall" instructions, etc.).
Traps typically need some way to preserve all userspace-accessible registers (otherwise resuming from a page fault is .. hard). Dedicated syscall instructions may only need to restore a subset of registers.
In some implementations, processors may discover that an instruction must trap after it starts irreversibly changing architecturally-visibile state; in cases like that, the processor needs to leave enough breadcrumbs for the OS to allow either a clean unwind or a resumption of the interrupted instruction. My understanding is that the original 68000 somewhat famously got this wrong.
Labor is not the only cost in that equation though, there's business regulations, the cost of the operators/repair that troubleshoot and repair the bots when they break, etc. a lot of which could be cheaper still than the price of a container on a slow ship from China.
This pattern of acquiring a company via debt financed on the value of the company is a leveraged buyout, is far from new and it's definitely quite corrosive to the finances of the new company. The pattern that plays out time and time again is the new debt from the acquisition severely hampers the new entity's ability to actually make the changes that might save them other than the chance to be raided by the buyer's management firm of choice.
Plus the random decision to split Google Assistant functions off from the bottom search bar. I still randomly try to tap that bar with it's mic button to ask the assistant to do something only to have it try to do a Google search. That's leaving aside all the random things that worked rather well in assistant until they started trying to push Gemini, can't think of a reason that should correlate (/s).
Also the homepage search widget, the app drawer search, and chrome address bar search are three near identical experiences, yet with enough differences to be painful. Either unify them, or make them distinct!
It acts like it is now but it used to act like it was one team and was an alternative assistant trigger, or you could even type to the assistant if you couldn't/didn't want to speak. Now that's basically only available via the "Hey/Ok Google" wake words and at best the bottom search bar uses the Google home page AI.
The $20B letter from TB is the leveraged part of the buy out and the math still doesn't add up even if you for some reason allow GME to dispose of all their cash in the deal without taking a hit to their stock price.
That's what those huge ~10% final value fees they charge are for. And other revenue such as sponsored listings (pay to boost your item in search results).
As long as they keep the fraud volume below like 5% of sales, I feel like it's just a numbers game, where they just need to get as much sales onto their platform as possible to give them enough operating margin to cover their costs (including fraud) and provide profit.
Admittely, I have no idea how well they're doing at that, I haven't looked at their financial statements or anything.
Yeah my main point was it's a complete pain in the ass to deal with if you want to do it properly in a way that actually prevents fraud on either side. eBay has kind of just erred one side or the other for most of it's existence and right now the complaints are mostly from the seller side that I see.
I guess that’s why the Amazon model works: if you warehouse and deliver, then you cut out a lot of the fraud.
Sellers gotta deliver one way or another anyway so building out that logistics doesn’t add much friction to the whole process at scale. If things turnover quickly enough, the first mile benefits exceed the warehousing expense.
Amazon's return policy is also getting pretty bad. There's a lot more third party sellers on the platform and occasionally users sent incorrect items get their refund refused because "item not returned" which is extremely frustrating when it happens. They're also kicking more people off for returning large numbers of items.
And as to GME trying to shift to that they did attempt that already, it was one of RC's first attempts at pivoting back in 2022, they added something like a million square feet of warehouse and fulfillment and it didn't really work.
The letter also said it was conditional on the combined entity maintaining investment-grade credit rating, which seems unlikely if the combined entity was saddled with $20B in debt.
reply