>V8 emits a near-jump for all forward jumps. If the target ends up too far away, the near-jump target is adjusted to a jump pool entry that contains a long-jump to the actual target
This sounds weird to me... Why not assume that all jumps need to be long to start with (so that the code is valid), then relax them to short jumps during an N-pass optimization stage- so that you get the smallest possible code?
Sounds like it's probably emitting the machine code in a single pass (compilation speed matters for a browser JIT), perhaps even together in a single pass with lowering (so don't even know the amount of instructions beforehand), and for such adjusting things afterwards would mean parsing & rewriting bytecode, and adjusting already-hardcoded backwards jump distances.
Maybe they benchmarked it and processors are so good at predicting the indirection, it doesn't matter much. In out-of-order processors there is a lot of untapped potential. As an example, Rust inserts bounds checks almost for free.
They only want the screen for the stereo and backup camera, not anything else. It's easier to update a car from 2004 say to have Android Auto than to fix one made in 2024 that doesn't have it. $400 aftermarket stereo from crutchfield..
I would say that 2005 was peak car, except 2000 is slightly better because they had not yet gone nuts with serialized components.
(another reason is that direct inject fuel injection hadn't taken over yet, it's a disaster)
So this link is interesting for a different reason: look at the references at the end of the paper. It's awesome that the references include URLs. IMHO, old papers should all be updated to include such hyperlinks.
I'm pleased that the references to other ACM papers do work.
But try to click on this one:
Bainbridge, L. 1983. Ironies of automation. Automatica 19(6): 775-779;
Fail! No way to read the paper without paying or pirating by using scihub (and even if you do get the .pdf via scihub, its references are not hyperlinks). This does not help humanity, it makes us look like morons. FFS, even the music industry was able to figure this out.
Shell sort is sooo much faster than Bubble sort for tiny microcontrollers, for only a little bit more flash memory, like 40-100 bytes. If that's too much, then Insertion sort is 6X faster than Bubble sort, for only 10-20 bytes of extra flash.
I'll say this about IBM: because it's so old, it was the most diverse company I ever worked for- including age, nationality, race, sex, and any other category you can think of. Basically you had all types of people in all stages of life, not just young white workaholic tech-bros. The founders are long gone, so everyone there (including CEO) is a professional- meaning nobody has any kind of personal attachment to the company. We were all in the same boat, as it were. When your older coworker suddenly disappears due to a stroke, it puts things in perspective.
The fast-paced startup is really the hack, combining the energy of youth with the ego-mania of their founders. Ask yourself, is it healthy?
Anyway, IBM's customers tend to be other fortune 100s and governments- basically other similar organizations, and my experience was that we took care of them pretty well. The products were not pretty (no Steve Jobs-like person to enforce beauty), and rather complex due to all the enterprise requirements. But they were quite high quality, particularly the hardware.
The awe induced when standing in front of a brand new, kitted out x95 frame with all its drawers full and that special shade of IBM blue on everything is definitely something. Pull out the HMC and just think about how many decades of R&D and experience and tears went into the entire system.
Hint: by all means possible, make sure you are not the owner of (or manager of the person who owns) any assets beyond your personal laptop. If, for example, you end up being the owner of all the development and test servers of the original company, then it will become your responsibility to ensure that each OS (of each LPAR of each VM) is security compliant, is running the end-point asset manager, and has up to date OS patches, that the DASD is encrypted, and you must periodically show physical proof that the asset still exists and indicate where it's located- photos of assets tags or whatever. It will be your responsibility to dispose of the asset (with all associated paperwork) at the end of its life.
It helps if such machines are not actually on the 9. network, or are behind an internal firewall (then they don't care about the security compliance as much).
Probably, but now it's going to be formalized and will entail a lot of paperwork (manual entry on many very badly written JAVA-based CRUD applications). Sure, these things are all good ideas, but trust me, they have all been overthought. Do you want this to be your job?
I still "own" (i.e. I'm the sole user with a root access and can install OS of my choosing) an old machine from the days before everything moved to a cloud and guess no one from IT has got to decommission it yet. I'm have no idea where it is located (besides knowing which office it is assigned to), never saw it, no way in hell am going to attach any tags and waste my time to install enterprise spyware on it or manually encrypt it's data. Do engineers do that for development servers on your job? If yes, name and shame!
You can measure it by how many management steps you, as an employee of the recently acquired company are from the CEO in the hierarchy. As time goes on, this number tends to increase. It used to be easy to see this in Lotus Sametime or something that had some form of employee directory.
That's awesome. Before ~2007 they allowed you to use open-source Pidgin to connect to the Domino servers. A friend of mine and I used it to make a bot: if you sametimed me, you got Zork.
It reminds me of another IBM IT rule: they wanted your chat history (and email) older than two years to be all deleted for legal liability reasons. It was important to save your sametime chat history (an XML file) and export your email periodically if you wanted to keep this stuff.
This was actually better than Slack in one way- you could grep the files for things, and not have to rely on search within the tool.
I built many such oscillators same way. But I used BC107 NPN, connected collector to the ground, emmiter to resistor/capacitornet. Base free. Add LED in series with such connected transistor, and you have LED blinker.
This sounds weird to me... Why not assume that all jumps need to be long to start with (so that the code is valid), then relax them to short jumps during an N-pass optimization stage- so that you get the smallest possible code?
reply