Hacker Newsnew | past | comments | ask | show | jobs | submit | Dwedit's commentslogin

How do you build a search index in the days of Anubis pages everywhere?

Unfortunately, search results on DuckDuckGo contain AI-generated descriptions. These sometimes contain mistakes.

That feature (Search Assist) can be turned off in the settings, and we have a noai.duckduckgo.com domain that automatically turns it off along with other AI features. That said, Search Assist just summarizes web content and does not generate its own answers, but the summary is AI generated.

I am not talking about the search assist, I'm talking about the descriptions that show up in individual page results.

Got it, thanks for the clarification. We have been working on our own web index that should ultimately help with that.

I can see by dragging the slider around and comparing to the ground truth that it is making things up that look plausible to what is there.

Just keep any numbers out of there. Remember what happened with the Xerox scanners and JBIG2 compression where numbers got substituted with similar looking numbers.


Did not work on PCEM for some reason.

Meanwhile the original ARM didn't use any microcode at all.

I wouldn’t say it didn’t have any microcode. It actually had a small PLA for sequencing the multi-cycle instructions. [0]

I don’t think anyone would actually label it as microcode (not when the entire point of RISC was to avoid microcode) they would call it a sequencer or finite state machine; But really it’s the same thing. It’s certainly much simpler than the full microcode of any contemporary CISC, and the bulk of instructions execute in a single cycle without using it.

If you want a design with zero microcode, you really need to look at MIPS, or the original Berkeley RISC. Those ISAs go out of their way to avoid multicycle instructions. Not entirely successfully, but they don't use PLAs [1] to implement any state machines for the few remaining instructions like multiply and divide.

[0] http://daveshacks.blogspot.com/2016/01/inside-armv1-instruct...

[1] At least on the few MIPS designs I've looked at. And I'm not sure if they deliberately avoided PLAs for doctrine reasons, or it was just more efficient to do so.


Yet their purity brought them no commercial benefit.

It turned out the die area saved by eliminating the complicated sequencer and microcode ROM enabled them to add another 16 datapath bits and make the first 32 bit microprocessor.

ARM got all the commercial benefit once they switched from making chips to providing full designs ready to integrate into other chips.

> to providing full designs ready to integrate

Yes, once the market came into existence, ARM was well situated to take advantage of it.

> all the commercial benefit

"All" is a tricky term to use here. They got some. An appreciable amount even. Their business model leaves quite a bit on the floor compared to desktop chips.


Are they finally marking all those functions that use IntPtrs as unsafe? (such as Marshal.Copy)

This change suggests that passing pointers is "generally safe", the unsafe boundaries are when they are de-referenced. It sounds like the Marshal methods are probably going to get a lot of surprising new safety warnings, but not all of them just because of the use of IntPtr. This change does open more opportunities to switch IntPtr to more explicit type-safe options like void* or byte* as the new compiler no longer needs unsafe {} blocks around just passing around pointers from one function to another.

Not really, because IntPtr is just a native-sized integer.

Marshal.Copy will certainly be marked unsafe, as will anything else that touches unmanaged memory.


GitHub won't let you upload a 7z file as an attachment for the issue tracker. Thus forcing me to use an inferior and obsolete compression format.

Then it's not a zip file anymore.

Just like if you modified PNG files to use zstandard instead of deflate, but otherwise be identical, it's still not a PNG file anymore.


That's not true. Zip files have supported other compression algorithms since the late 90s.

I guess its PNG v2 then? ;)

Anubis is actually not a cat. The original Egyptian deity is a god of death, and has a canine head. Anime catgirls and dog girls can look similar at first glance.

I believe they are referencing the person who wrote the program, not the name itself.

More likely to be referencing the mascot character who appears on your screen when you visit a protected page.

If you want to write faster Z80 code, pretend it's a Game Boy, and use the IX/IY registers sparingly. You can use 256-byte aligned tables. Then you put your index into the low byte of the register pair, and which table into the high byte of the register pair. You don't even need to completely use the table if you don't need all 256 entries, you can treat the rest of a table as free space to put other variables in there.

edit: At the time I made the post, the thread title was something like "Doing Z80 40 years later", and did not mention the ZX spectrum.


If you want to fill values into memory, use PUSH xx instructions. Just move the SP to right position and starting pushing. It's faster than LDIR.

Just make sure you don't mind the interrupts also writing to that memory...

It’s a Spectrum. You’re going to do a HALT to sync with the start of the frame and then cycle count to prevent tearing. You can disable interrupts if you know how long you have to render your frame before the beam catches you (or let it pass then start rendering).

So basically an 8080

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: