3 ms·
I don’t think so, except at the margins. I started out as a Lisp hacker on machines designed for it (PDP-10 and CADR, later D-machines) so I was very much in t
by gumby 4y ago
I don’t think so, except at the margins.
I started out as a Lisp hacker on machines designed for it (PDP-10 and CADR, later D-machines) so I was very much in the camp you describe. They had hardware / microcode support for tagging, unboxing, fundamental Lisp opcodes, and for the Lispms specifically, things like a GC barrier and transporter support. When I looked at implementations like VAXLisp, the extra cycles needed to implement these things seemed like a burden to me.
Of course those machines did lots of other things as well, and so were subject to a lot of evolutionary pressure the research machines were not subject to.
The shocker that changed my mind was the idea of using the TLB to implement the write barrier. Yes, doing all that extra work cost cycles, but you were doing on a machine that had evolved lots of extra capabilities that could ameliorate some of the burden. Plus the underlying hardware just got faster faster (I.e. second derivative was higher).
Meanwhile, the more dedicated architectures were burning valuable real estate on these features and couldn’t keep up elsewhere. You saw this in the article when the author wrote about gates that could have been used elsewhere.
Finally, some decisions box you in — the 64kb object size limitation being an example in the 432. Sure, you can work around it, but then the support for these objects becomes a deadweight (part of the RISC argument).
You see this also in the use of GPUs as huge parallel machines, even though the original programming abstraction was triangles.
Going back to my first sentence about “at the margins”: optimize at the end. Apple famously added a “jvm” instruction — must have been the fruit of a lot of metering! Note that they didn’t have to do this for Objective-C: some extremely clever programming made dispatch cheap.
Tagging/unboxing can be supported in a variety of (relatively) inexpensive ways by using ALU circuitry otherwise idle during address calculation OR (more likely these days) by implementing a couple of in demand ops, either way pretty cheap.
Finally, we do have a return to and flourishing of separate, specialized functional units (image processors, “learning” units and such, like, say, the database hardware of old) but they aren’t generally fully programmable (even if they have processors embedded in them) but they key factor is that they don’t interfere (except via some DMA) with the core processing operations.
- panick21_ 4y agoNot adding tagging is basically a negligence crime. That feature isn't that expensive and it could have saved most of the security issues that have happened to last 20+ years.
- Lammy 4y agoNSA et al probably like better it that way so they have easier access to the "'intel' inside" my PC.
- panick21_ 4y agoThat's an incredibly bad argument because these are the same computer the NSA and the US govenrment itself uses and they are exposing themselves. Not to mention all the US company who are subject to intellectual property theft and so on.
- gumby 4y agoUnfortunately the Information Assurance part of NSA’s mission seems to have diminished dramatically in the 21st century. But your point still stands about in house use.
- aardvark179 4y agoI think you are talking about different types of tagging. Tagging on Lisps and other language VMs is where some bits in a pointer are reserved to indicate the type. So with a single tag bit integers might be marked as type 0 (so you don’t need to shift things when doing arithmetic) and other objects would be type 1. This provides no real protection against malicious code at all. There are other types of pointer tagging that do provide security, and we are starting to see some support in hardware.
- panick21_ 4y agoIts the same basic concept you can use in multiple ways. But yeah of course security was not what tagging was used.
- astrange 4y agoIntel does have a pointer tagging feature called Linear Address Masking. Why it's called that I don't know. (On ARM it's called TBI/top byte ignore, on AMD it's called UAI/upper address masking.) This is different from pointer signing which it doesn't have.
- aardvark179 4y ago“Going back to my first sentence about “at the margins”: optimize at the end. Apple famously added a “jvm” instruction — must have been the fruit of a lot of metering! Note that they didn’t have to do this for Objective-C: some extremely clever programming made dispatch cheap.” I’m struggling to think of what you are referring to here. ARM added op codes for running JVM byte code on the processor itself, but I think those instructions were dropped a long time ago. ARM also added an instruction (floating point convert to fixed point rounding towards zero) as it became such a common operation in JS code. There have also been various GC related instructions and features added to POWER, but I think all that was well after Apple had abandoned the architecture. I may be forgetting sonething, could you clarify?
- mananaysiempre 4y agoGP probably meant a “JS” instruction rather than a “JVM” one: FJCVTZS, “Floating-point Javascript Convert to Signed fixed-point rounding towards Zero”[1,2], introduced in ARMv8.3 at Apple’s behest (or so it is said). Apparently the point is that ARM float-to-integer conversions normally saturate on overflow while x86 reduces the integer mod 2^width, and JavaScript baked the x86 behaviour into the language. [1] https://developer.arm.com/documentation/ddi0602/2022-12/SIMD-FP-Instructions/FJCVTZS--Floating-point-Javascript-Convert-to-Signed-fixed-point--rounding-toward-Zero- https://developer.arm.com/documentation/ddi0602/2022-12/SIMD... [2] https://news.ycombinator.com/item?id=24808207 https://news.ycombinator.com/item?id=24808207
- gumby 4y agoI meant JS but too late to edit.