Validark

I am not suggesting that quad be mandatory, just that machines which do support quad could allow addp et al to work on quads in the way I’ve described. The specializer could break those up for lower-end Mills, couldn’t it?

If it’s possible to OOM upon writing to the scratchpad, is it possible to recover from that? Are there ways to guarantee you won’t OOM? What are the things to avoid?

Don’t higher-end Mills already support native 128 bit operations? Of course, machine width can support this feature as well but supporting {addr,len} pointers directly would allow one to run more operations simultaneously (on higher-end Mills), which could be a big win in some scenarios where you want to do two {addr+1,len-1} ops in a cycle while also doing something else. It would also make things fall off the belt slower when using multiple fat pointers. The {addr,len} scheme doesn’t seem terribly specialized to me. To me it seems quite general-purpose and applicable to a wide variety of programming languages. I think most languages probably use {addr,len} all over the place. In many cases things have a capacity field too but that doesn’t change during iteration so that can sit elsewhere.

With regards to backwards iteration, I’d assume one could use subp, although I don’t particularly care what the semantics are as much. I have personally only used fat pointers for forward iteration and I do not know how most languages support backwards iteration, if they even do (in Go, C#, and JavaScript, for example, one cannot go backwards with a blessed for..of/foreach loop, you have to manually index in or reverse the data in an array). The languages that do support backwards iteration appear not to give access to any data besides the current element (and perhaps whether there is another element to iterate over next). I think supporting backwards iteration through this mechanism is thus less important, but a language could theoretically construct a fat pointer which points to an element and the things to its left rather than to its right, and then iteration could be done the by doing subp which would do {addr-1,len-1}. It wouldn’t support going forwards and backwards randomly (unlesslenis just how many elements one wants to touch before stopping), but I’ve never used an iterator like that anyway and most iterators can’t do that anyway. If I were doing something that weird, I wouldn’t expect the benefit of operating directly on pointers, I’d have an index into an array. The point of allowing addp to work on 128 bit fields directly (on high-end Mills) is to make the machine wider in the most common case, and iterating forwards is by far the most common case. Of course, on Mills with less width and no 128-bit data paths, yeah, they will have to issue two ops and two drops on the belt to do each fat pointer operation. Also, in the case where reversed iteration is abstracted away: great! You can just do it in whatever way is most efficient for the Mill (at least in 99% of cases).

I doubt anyone would want to garbage collect a Fat pointer that’s been modified by iteration (although one could, but it would take more bookkeeping and effort). E.g. in Zig when you deallocate you are expected to give back the full slice / fat pointer that was given to you by the allocator originally, without changes achievable by forward iteration (there is no blessed way to move a fat pointer backwards in Zig, you have to reconstruct it yourself). I think this problem currently is accounted for by most languages and the addp overloading idea I had doesn’t conflict with garbage collection whatsoever.

Anyway, this is just an idea that I thought might be a nice optimization for high-end Mills to improve width and belt space in practice. Thank you for your consideration.

• This reply was modified 1 year, 7 months ago by  Validark.

A well-placed tweet woofe (is that what sound doge’s make?) at Elon Musk might be enough to get it in Teslas, haha.

I think another great market would be e-ink devices (e-readers and note takers). Elimisteve remarked in the forum that phones and tablets spend most of their battery on screens and that a more efficient CPU wouldn’t necessarily give massive gains. Although I’d still prefer to have a Mill-backed phone, e-ink devices are an interesting, niche market where screens generally take a lot less power. Battery life is typically measured in weeks, not hours or days. From what I can surmise, power consumption of the CPU is difficult to balance against the ideal high performance chips that ideally would be in these devices. I follow what devices come out and what companies are in this space and I have seen a lot of marketing materials for high-end devices where the beefier CPU is the second selling point, behind the screen type, of course. These devices all want to reduce input latency (and improve speeds in general) but none of them can compete with the dedicated monitors from Dasung due to CPU/power limitations (Boox has standalone monitors too but aren’t able to squeeze the same performance out of an identical panel). This is also a space where a lot of devices have custom Linux OS’s, although many do use Android, for those who want to “side-load” Android apps to get more functionality outside of what the device ships with by default. Could this be an opportunity for the Mill?

Companies include SuperNote, Onyx Boox, ReMarkable, Kobo, Pocketbook, BigMe, of course Kindle and Nook, Sony, Huawei, Fujitsu Quaderno, Bookeen/Vivlio (just learned of this one just now), Lenovo, and if you check goodereader you’ll find there are even more companies that cater exclusively or at least mainly to the Chinese market. Dasung has released some non-monitors too but thus far they are known for not investing in good software.

I’d be surprised if all of these companies passed on the Mill. I think the Mill should be a good fit for these devices that want more horsepower but better power efficiency.

Does the Mill have any instructions that can directly support fat pointers? E.g. in Zig I can do cur = cur[1..];, where cur has a ptr and len field, each a machine word, and this will add 1 to the ptr and subtract 1 from len. It would be cool if addp e.g. could work directly on fat pointers. I.e. In the case that addp is given a fat pointer as an argument, it would simultaneously add to the pointer and subtract from the length, giving back a 16 byte fat pointer with the pointer half increased and the length half decreased (assuming you are on a Mill member with where each slot on the belt can hold 16 bytes). If the length goes below 0 it should return a NaR.