BobC

My brother-in-law works for a small physics startup that in January started looking for another Angel to get through COVID. They wound up getting 3 VCs in March. (The 3 VCs were to ensure share dilution, not to get 3x money.) Not sure how that came to happen (who talked to who), but the money is out there.

• This reply was modified 3 years, 6 months ago by  BobC.

You know, just when I think I want to share some insight, I once again realize we’re still chipping flakes from the periphery The Mill’s Big Picture. It’s like every “Ah-ha!” reveals just how much more of this there is to disclose.

As Ivan repeatedly promised, the lectures are a “gross oversimplification” of The Mill reality.

The last processors I worked on that were a “compiler writer’s dream” were the CISC VAX and 68K. When Ivan mentioned the B6500, another easy compiler machine, I was immediately thrown back into the reason the B6500 hardware was so expensive: Stack machines are DOA without fast memory, and the fast B6500 memory was terribly expensive. (You could buy slow memory, but why?)

Then I worked on a CDC machine, and I saw the light: Speed is king, Then you have to do the software. Seymour Cray was my hero. Don’t know Seymour: Check this out:

I appreciate Ivan’s emphasis on The Mill being a software-driven hardware architecture, but I’m beginning to hunger for some examples (however trivial) of how the hardware implementation will be accomplished. Block diagrams or schematics would suffice, but I’d kill for some VHDL/Verilog to play with.

The portal/service concept, along wiht much of hte rest of the Mill security architecture, would appear to be useful as a enhancement/modification to other CPU architectures. It appears to be lighter weight and more powerful than a traditional MMU (well, Memory Protection Unit, since there’s no hardware virtual memory on the Mill).

The Mill is a 64-bit machine with a massive 60-bit physical address space (“an exabyte should be enough for anybody”), so an MPU is more appropriate. But there are lots of other processor uses that would benefit from a flexible MPU managing non-virtual memory: Just about every embedded system (my specialty).

Do you think all or part the Mill security model could be usefully ported to 32-bit embedded processors? If so, is MillComputing considering any of the following?

1. Port Mill innovations to existing architectures (with available IP: ARM, Nios, Mips, etc). (This could allow MillComputing to get fab experience and hardware revenue before the Mill itself is ready for roll-out.)

2. License Mill innovations to those wanting to incorporate them into existing architectures. (License revenue, like ARM.)

3. Some combination, where an experienced fabless partner (say, Qualcomm) would get limited Mill IP (for Snapdragon) in exchange for helping push the Mill toward silicon.

Yes, ARM and Nios already have MPUs available, but they seem primitive compared to the Mill security architecture.

Personally, I’m leery of using other login credentials because of the metadata expansion for honest users. Every credential use lets that service know that their user has used their credential to authenticate at OOTBC.

After all, it is easy for a less-than-honest person to create a fake account on one of those services, then use it as a credential. So adding an external login authority actually adds little protection for the forum, and only a tiny bit of convenience for users.

Account creation should certainly require an email address with a validating message, with a captcha for bot resistance. That’s already present, and is pretty much what those other services use.

Browsers are good at managing login credentials, so there is not even much convenience benefit to using an external authority. The only benefit MAY be for non-browser use, if any such thing is supported by this forum.

• This reply was modified 10 years, 10 months ago by  BobC.