William, On 5/27/08, William Pearson <[EMAIL PROTECTED]> wrote: > > 2008/5/27 Steve Richfield <[EMAIL PROTECTED]>: > > Systems now crash NOT because of the lack of some whiz-bang technology, > but > > because architectural development has been in a state of arrested > > development for the last ~35 years. > > It is not just crashes that I worry about but memory corruption and > other forms of subversion.
This all is the result of poor design. For example, the old Burroughs hardware performed all computed-address operations via array descriptors, which not only showed where the array began, but also what all of its dimensions are. Where multiple subscripts were used, the multiplication needed to be done to compute the address was all done in the hardware by implication, and only after each of the bounds were checked. Note that this costs NO more time when the additional hardware needed to perform this in parallel is included in the design. > > >> This should allow the system to change as much > >> as is possible and needed for the application under consideration. > >> Currently the project expects to go to the operating system level > >> (including experimentation on schedulers and device drivers). A > >> separate sub-system supplies information on how well the experiment is > >> going. The information is made affective by making it a form of > >> credit periodically used to bid for computational system resources and > >> to pass around between programs. > > > > > > This sounds like a problem for real-time applications. > > In what sense? Because real-time applications typically need whatever they need RIGHT NOW. Windows is woefully inadequate for real-time applications, as I discovered when I interfaced Dragon NaturallySpeaking to my AI program. It would often stop for many seconds while new things were paged into memory, run slow as complex components were kicking each other out of cache, etc. > > Whoops, there are SERIOUS limitations to what can be made reliable in C. > > C is purely the language for the VRRM, what the programs will be > implemented inside the VM is completely up to the people that > implement them. > > >> > >> Progress > >> > >> Currently I am hacking/designing my own, but I am open to going to a > >> standard machine emulator if that seems easy at any point. I expect to > >> heavily re-factor. I am focussing on the architectural registers, > >> memory space and memory protection first and will get on to the actual > >> instruction set last. > > > > > > This effort would most usefully be merged with the 10K architectures that > I > > have discussed on this forum. Merging disparate concerns might actually > > result in a design that someone actually constructs. > > Possibly after I have completed the VRRM and tested it to see if it > works how I think it works. But silicon implementation is not on the > agenda at the moment. My whole point was that reasonable architectures would eliminate some/many of the problems that you seek to fix. >> I'm also in parallel trying to design a high level language for this > >> architecture so the internals initial programs can be cross-compiled > >> for it more easily. > > > > > > Does this require a new language, or just some cleverly-named > subroutines? > > A different set of system calls in the least. Some indication of how > important the memory is in dynamic memory creation is needed for > example. Isn't this just a small-RAM problem? Wouldn't a few more gigs of RAM obviate this, and be available before your software is completed? >> Current Feature plans > >> > >> - Differentiation between transient and long term storage to avoid > >> unwanted disk thrashing > > > > > > Based on the obsolete concept of virtual memory rather than limitless > RAM. > > We don't have limitless RAM, It's getting pretty close. and I won't be implementing virtual memory. > <snip because I don't have time> > > > >> > >> - Specialised Capability registers as well as floating point and > integers > > > > > > Have you seen my/our proposed improvements to IEEE-754 floating point, > that > > itself incorporates a capability register?! Perhaps we should look at a > > common design? > > Do you mean capability in the same sense as me? Perhaps not, but shouldn't all capabilities be kept together? Bits would enable various features and differences, e.g. gradual overflow, logarithmic representation, significance representation, etc. This can be a global characteristic when a program is communicating floating-point to other programs. Steve Richfield ------------------------------------------- agi Archives: http://www.listbox.com/member/archive/303/=now RSS Feed: http://www.listbox.com/member/archive/rss/303/ Modify Your Subscription: http://www.listbox.com/member/?member_id=8660244&id_secret=103754539-40ed26 Powered by Listbox: http://www.listbox.com
