OSDev.org

The Place to Start for Operating System Developers
It is currently Wed Jul 26, 2017 4:46 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 136 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10  Next
Author Message
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Sat Apr 22, 2017 10:54 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 886
Location: Athens, GA, USA
Ah, I found the one I had in mind. It is rather interesting and full of insights into how modern CPUs actually work, and not just regarding x86-64.


_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
μή εἶναι βασιλικήν ἀτραπόν ἐπί γεωμετρίαν
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Sat Apr 22, 2017 11:15 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 886
Location: Athens, GA, USA
I also took a look at a video on Mill while looking for it, an architecture which has been mentioned here numerous times before but which I never took the time to really look into, and along the way ran across the central design idea of it, the belt machine model. I think if I ever revisit RSVP as a design idea, I would probably need to consider using the conveyor structure rather than the stack I had originally envisioned. If I ever get my life together, and get into grad school on a PhD track (as I should have done 25 years ago), I might want to see if I can get a project for a prototype RSVP put together in some university's prototyping fab. Where I would get the $1 million to $5 million grants needed for that would be another matter.

I am sure several of you will note the x100 difference in what I am saying this would cost, versus my earlier minimum estimate for developing a commercial product version of an OISC. The key words here are 'prototype' and 'commercial product'.

Building an OISC using a field-programmable device? pretty much the cost of the FPLA or FPGA, the device programmer (the device that writes to the PLD, not the human software developer), and a breadboard, plus the time to program it - maybe $30 US if you already have the device burner. Building a TTL OISC, maybe $50-$100, and don't even consider how it performs (for the record, terribly, by current standards - lightspeed considerations ensure that no TTL system can compete with integrated silicon, even compared to a programmable logic array, because it will take longer for a signal to go from one chip to another than it would take for the PLD to complete the operation).

Designing an ASIC and getting it fabricated? Several thousand dollars, to hundreds of thousands depending on how far you take it, and its performance probably won't be significantly better than the FPGA implementation (they are basically the same technology, but a custom ASIC can be better optimized - sometimes). This, by the way, is the technology most chipsets use, or at least used to (I am guessing it has moved on since then, but I would need to check).

Designing an unoptimized prototype or proof of concept in a small-scale silicon foundry of the sort owned by some universities? $500,000, minimum. Yeah, that's quite a jump. Note that while the cost for creating the RISC-I is usually given as around $100,000 IIRC, that was in 1981 - the adjusted cost would be around $850,000, I think, so the real cost has dropped considerably.

Developing a commercially viable, optimized IC layout and implementing it in a fab's development line? There's the $2 billion I quoted earlier.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
μή εἶναι βασιλικήν ἀτραπόν ἐπί γεωμετρίαν
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Sat Apr 22, 2017 2:59 pm 
Offline
Member
Member
User avatar

Joined: Tue Aug 02, 2016 1:52 pm
Posts: 284
Location: East Riding of Yorkshire, UK
Schol-R-LEA wrote:
Several thousand dollars, to hundreds of thousands depending on how far you take it
Sorry for going a bit off topic, but where can you get an ASIC fabbed for a few thousand dollars? I can only think of TSMC and GlobalFoundry off the top of my head, but I don't even think they'd bother responding to you if all you had was a few thousand.

_________________
com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState
Compiler Development Forum


Top
 Profile  
 
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Sat Apr 22, 2017 3:23 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 886
Location: Athens, GA, USA
matt11235 wrote:
Schol-R-LEA wrote:
Several thousand dollars, to hundreds of thousands depending on how far you take it
Sorry for going a bit off topic, but where can you get an ASIC fabbed for a few thousand dollars? I can only think of TSMC and GlobalFoundry off the top of my head, but I don't even think they'd bother responding to you if all you had was a few thousand.

OK, I was probably off by a lot on that, come to think of it. Yeah, I blew it there, but if anything, that only reinforces my point.

There is a world of difference between a hobbyist making an OISC implementation with an FPGA or a hand-wrapped breadboard full of discrete ICs, and even the lowest end consumer-grade implementations. It is like comparing a Ford or a Toyota made in a factory to a life-size model made from Legos by some ambitious teens.

A student project on designing a new architecture using a dinky University-owned fab isn't at all the same as a professional product, either. Interestingly enough, for what it can actually accomplish, the University foundry will cost a lot more overall for the results than the professional foundry, it's just that what can be accomplished by a University fab and what a company like Intel or GlobalFoundry can do are not really comparable.

One of the rarely-mentioned aspects of RISC is that the Berkeley RISC I and Stanford MIPS 1 designs were originally developed because simple, no-frills CPUs with no microcode was the most that the fabs owned by UC-Berkeley and Stanford U. were up to producing, as well as being the most which could be covered in a two-semester graduate courseload. It was a real shock to find that these stripped down architectures proved to be as fast or faster than the commercial microprocessors of the time, and even some of the minicomputers (this was back when a TTL design actually could outperform a contemporary microprocessor, sometimes, due to the limits of IC designs, transistor densities, and silicon real estate of the day). The RISC revolution got underway precisely because of how inefficient the mainstream designs of the time were.

This is itself yet another nail in the coffin of Geri's claim that an OISC can be made by a startup on a shoestring and then sold for US$1 apiece in the sort of volumes that a startup can make them in (i.e., production runs in the hundreds rather than millions, even when going fabless and contracting the actual production - which means that the unit costs would have to be astronomical to defray the development cost).

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
μή εἶναι βασιλικήν ἀτραπόν ἐπί γεωμετρίαν
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Sun Apr 23, 2017 2:47 am 
Offline
Member
Member
User avatar

Joined: Tue Aug 02, 2016 1:52 pm
Posts: 284
Location: East Riding of Yorkshire, UK
Schol-R-LEA wrote:
OK, I was probably off by a lot on that, come to think of it. Yeah, I blew it there, but if anything, that only reinforces my point.
Aww, you got me excited there.

Schol-R-LEA wrote:
A student project on designing a new architecture using a dinky University-owned fab isn't at all the same as a professional product, either. Interestingly enough, for what it can actually accomplish, the University foundry will cost a lot more overall for the results than the professional foundry, it's just that what can be accomplished by a University fab and what a company like Intel or GlobalFoundry can do are not really comparable.
I never thought about universities having their own fabs. Looks like the one smallest process they can do at Berkeley is 380nm. For reference the latest AMD chips use a 14nm process.

_________________
com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState
Compiler Development Forum


Top
 Profile  
 
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Sun Apr 23, 2017 9:45 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 886
Location: Athens, GA, USA
matt11235 wrote:
I never thought about universities having their own fabs. Looks like the one smallest process they can do at Berkeley is 380nm. For reference the latest AMD chips use a 14nm process.


Note that this is after repeated upgrades; a page I found states the process used in 1981 was 5μm (5000 nm). I have not been able to find the process density used for the MIPS 1 at Stanford, but I expect it was similar.

To further put this in context, according to Wicked-Pedo, that's the same process density that Intel was using on the 8085, four years earlier. The process Intel used for the original 8086 in 1978 was 3μm, as were the processes used in the 8088 a year later, the Commodore-Mos Tech WDC-65C02 in 1982, and the ARM I in 1985 (!!!). Just to drive home the point about Intel's lead over most of the other companies, the 68000 was using a 3.5μm process in 1979, the same year as the 8088 - and Motorola was Intel's primary competitor. Intel, AMD, and Acorn were using 350nm processes in 1997, meaning that the gap in time for the implementation of higher density processes has widened tremendously, though it may just be because the universities don't need more (after all, they can only cover so much in a few semesters, and foundries are very expensive - even for research, the schools simply can't match the budgets of the corpse-rat developers).

The take-away:
  • Right now, Intel, AMD, and nVidia are just about neck-and-neck, though AMD seems to have pulled ahead right now. No one else seems to comes close to them, even the memory, ASIC, and FPGA manufacturers. Even Oracle is using a 20nm process equivalent to that used on Ivy Bridge, though that may be partly due to Oracle not really giving much of a damn about SPARC or anything else they got from Sun except MySQL (they bought the company primarily to kill off that single 'product', or at least get control over it; the rest is just excess baggage, and their main interest in them is in how much they can get people to cough up for Java certification classes).
  • With the exception of the introduction of 32-bit p-mode in 1985, and 64-bit long mode in 2001, most of the improvements in performance for the x86 (and processors in general) since then have depended on the improved process. These come mainly from lower signal delays, but have also been because they could simply do more per square nm of chip real estate (and now cubic nm, with the multilayer processes). Intel and AMD have thrown a mountain of work on using those improvements to speed up the x86, and are now really good at it, but I can't help but wonder what would have happened if that effort had been put into a design such as MIPS, SPARC (which descends from the Berkeley RISC), PowerPC, Alpha, or even the M680x0 or the Transputer (and yes, INMOS was a big influence on my RSVP idea). The point is, these speed ups wouldn't even have been possible in 1978, even for the design principles which were already known at the time (which was most of them, actually - most have their roots in the CDC mainframes and Cray minisupers), simply because the chips couldn't have held all of it. The rise of RISC was compensating for something that is no longer an issue.
  • A lot of the reason why RISC was so much better at the time was because most of the commercial microprocessor designers were focusing on features rather than performance. The real take-away from RISC was that trying to do too much in hardware rather than software was actually hurting performance, especially as increased use of compiled languages made the assembly language bells and whistles of something like the VAX or the 68000 redundant.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
μή εἶναι βασιλικήν ἀτραπόν ἐπί γεωμετρίαν
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Last edited by Schol-R-LEA on Sun Apr 23, 2017 4:56 pm, edited 3 times in total.

Top
 Profile  
 
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Sun Apr 23, 2017 3:13 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 886
Location: Athens, GA, USA
Perhaps we need to re-rail this conversation, and possibly Jeff the thread into two or more different discussions. Or lock the thread, one or the other. Either way, we're quite far afield at this point.

EDIT: after looking once more at the train wreck that is the first post of this thread, I think locking - and deleting - is probably the better choice. Seriously, I know that English isn't your native language, but this 'tutorial' is so incoherent, scattershot, and full of paranoid nonsense that I think even Swampy would say "WTF?" about it. It is a perfect example of something that is Not Even Wrong. It isn't even amusingly stupid; it's just garbage.

I've heard Birchers rant about A. Wiseguy and the Aluminum Bavariati fnord with more cogency and reason.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
μή εἶναι βασιλικήν ἀτραπόν ἐπί γεωμετρίαν
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Last edited by Schol-R-LEA on Sun Apr 23, 2017 10:44 pm, edited 3 times in total.

Top
 Profile  
 
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Sun Apr 23, 2017 4:05 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 886
Location: Athens, GA, USA
gerryg400 wrote:
Subleq seems like a thoroughly stupid idea. Geri, is it actually as stupid as it seems? Are there any actual advantages or is the whole idea just a curiosity?


It, and OISCs in general, have several theoretically interesting properties regarding computability and the Church-Turing Thesis. However, as practical systems, you would probably be better off trying to build and use an electromechanical UTM - that is, one composed of a paper tape reader/writer/eraser and a comparison gear - instead.

(I think someone actually did that once, probably as a demonstration unit at the old Boston Technology Museum or something similar. Turing himself only intended it as a conceptual model, and did it as 'concrete' as he did to make it clear, rather than out of practicality - the actual computers he helped design were nothing like the Turing Machines from "On Computable Numbers", and for good reason.)

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
μή εἶναι βασιλικήν ἀτραπόν ἐπί γεωμετρίαν
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Sun Apr 23, 2017 5:00 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 886
Location: Athens, GA, USA
As snide as I was earlier, I am curious as to whether Geri has considered what I said about C not being the most appropriate high-level language for implementing on an OISC. I really do think that if he is going to continue on this path - for good or for ill - he really should look at things like FSAs and the Dataflow and Constraint paradigms. Steam engines when it is steam engine time; a state machine language for an instruction set that is itself basically a state machine.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
μή εἶναι βασιλικήν ἀτραπόν ἐπί γεωμετρίαν
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Sun Apr 23, 2017 6:14 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 886
Location: Athens, GA, USA
I keep coming back to this... I must be getting as obsessed as Geri...

While I don't think that OISCs make good general-purpose CPUs, I can see one, or something like one, as the unit of a specialized systolic array that could be used as a signal processor or part of a larger CPU - in other words, as nodes in precisely the sort of DSP or GPU you seem to think are such a bad idea. However, that's a really, really sketchy proposition, and not one I see anyone backing as a production device unless a lot more research and development proves it useful - it isn't really all that different from existing DSPs, so it would need to show some spectacular advantages to make it usable.

One thing I need to impress is that my statements are not about your interest in Subleq based systems itself, but in the claims you are making about them - and the conspiratorial tone you are using when discussing existing systems. I am all for new ideas, but they need a lot of proving and refining before they can be used in a practical setting.

The Subleq instruction, and the proof that it is Turing-complete, dates back to the mid-1960s; don't you think that if it were a viable system, someone would have at least tried to use it in a commercial system by now? I won't say it will never work - I have no idea what may happen in the future - but today it just makes no sense given the technology and the state of our understanding of the idea.

(The one class of OISCs that has been used commercially, in software, is a specialized one for cryptography and cryptanalysis. Interestingly enough, IBM has also sold ZISCs for specialized neural networking projects as well, though apparently they have discontinued them. Even more esoteric computation models such as Petri nets and even Calculus of Indications have also been used; yea, do many things come to pass.)

There is a saying in some engineering disciplines which the WTFers are fond of repeating: any new idea has to be measured not from 0, but from -100 (or lower). This is in part to compensate for the natural enthusiasm that someone working on an idea has, but also to account for the resistance to change which is inherent in most commercial markets. You have to prove not only that the idea is better than the existing one, but that it is dramatically and overwhelmingly better. You have yet to do this so far. Maybe you will some day, but so far, no.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
μή εἶναι βασιλικήν ἀτραπόν ἐπί γεωμετρίαν
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Mon Apr 24, 2017 11:39 am 
Offline
Member
Member
User avatar

Joined: Sun Jul 14, 2013 6:01 pm
Posts: 392
Schol-R-LEA: yeah, the thread fusioned from subleq, isa-s, x86 platform topics together into, but i am not sure if it can be split, becouse this three kind of topic only viable compared to the other two. yeah, some univerities are having chip manufacturing production lines (i not yet was able to crawle any of my minions into one yet) and they are having courses to put easy chips together (and well now i can give them a very easy chip to meditate on it).

_________________
Operating system for SUBLEQ cpu architecture:
http://DawnOS.tk


Top
 Profile  
 
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Sun Jul 16, 2017 3:25 pm 
Offline

Joined: Sun Sep 11, 2016 12:54 pm
Posts: 5
Quote:
4. However, in real mode, you cant have 64 bit mode. To have 64 bit mode, you will need to
have protected mode, and then you enter the long (64 bit) mode. Having 64 bit mode
is however only supported on the newer x86 processors, begining from the last generation of
Pentium4 (pentium D) CPU-s, and Athlon64 (k8).


Small nit: You can get effective 64 bit real mode with what I call an "identity page set". Before entering 64 bit mode, you construct a page set that maps virtual pages for all of memory to the same page in physical address space. This means when you flip on 64 bit mode, nothing will move, and all addresses remain the same. I used this trick when the opteron came out because I was shipping a debug package for a new system and didn't want to be bothered with paging and needed direct access to the MMIO hardware. A page table is easy to construct with code, especially if it is an identity map.\

Scott Franco
San Jose


Top
 Profile  
 
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Sun Jul 16, 2017 6:01 pm 
Offline
Member
Member

Joined: Fri Aug 19, 2016 10:28 pm
Posts: 93
Schol-R-LEA wrote:
The basic concept is to eliminate the majority of the registers in the CPU, replacing them with large (>1M) write-through caches.
I was thinking about something related a couple of weeks ago. The register part particularly. I was questioning, what are the benefits and drawbacks of using registers instead of cached memory or vice versa ... and I couldn't answer satisfyingly.

In my view, registers are just another memory tier that is simply closer to the CPU and does not participate in the global address space (, which makes it exempt from coherency detail). Most of its performance effects compared to caching, I figured, should be due to the explicit management of its occupancy. I don't know how to analyze the effects from that, fundamentally.

Provoked by the RSVP proposition here, I tried a different angle. What would happen if CPU without registers was implemented with Nx8 bytes of register-speed associative cache (where N is the number of eliminated registers, say 16<=N<=64) instead of 1M as in the RSVP? I know this alters the proposition, but the point is to just put the conventional design and the new memory layer on an equal footing, in terms of silicon estate and distance from the ALU. I am not talking about RSVP overall here. So, when threads get switched, due to that cache being small, the instructions could and probably would initially evict and fetch operands from the next tier. That is, threads would stall in effect due to the context switch, albeit from parasitic effects from it, rather than as a direct consequence. Which is (grossly speaking) similar penalty to the cost of saving the register context explicitly, but with ability to adaptively write back fewer cache lines if the dirty set is small. This however, wouldn't be the case frequently with 16x8 bytes or even 64x8 bytes of cache.

May be (and I don't know really) more memory could be stacked closer to the ALU anyway, with little effort or performance tradeoff, and thus the first memory tier could indeed be easily made 1M. In this case, conventional CPU design could be defended by saying that such space would provide more shadow register sets and 1M worth of hyper-threading support without context switching penalties. (Obviously I am ignoring TLB and address space switching penalties.)

My point is, I like the idea of register-less ISA, but I wonder whether it has performance consequence when placed on an equal footing. The question seems to me to be, can 1M of memory be brought as "close" to the ALU as the register file is today, or at proportionally what cost. Also, how does that compare to hardware context switching with shadowed registers of the same total capacity (which I confess I find to be the messier approach anyway).


Top
 Profile  
 
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Sun Jul 16, 2017 11:36 pm 
Offline
Member
Member
User avatar

Joined: Tue Mar 06, 2007 11:17 am
Posts: 981
Registers are the minimal set of CPU variables. Besides that, each register has special tasks defined statically by the CPU core architecture, so they aren't just variables but also have fundamental tasks assigned to them per each instruction and for the general execution.

They are part of what defines the machine word size that a programmer is able of gathering in a single fetch or store memory operation.

Part of the cache would be accessed by the CPU registers, so registers could be seen as the topmost window into the calculations between registers and the contents of memory. So registers would simply be the last and most superficial level window/visor to all of the state of the memory and devices in a system. Somehow thing will also end up in a minimized data structure that can be used concisely by software, in this case the set of registers are what achieves that.

Hard disks have a register file, a set of contiguous registers.

PCI has registers.

VGA has registers.

The FPU has registers.

All of those things need to keep variables when they don't have their own memory space in RAM to store things in.

A cache is probably not intended to hold a persistent record of the execution state, so in one way or another we always end up reserving some sort of registers.

If we see the instructions at the bit level, we can see that the registers, register sizes and memory indexes are just indexes interpreted in a certain addressing mode, they obviously don't even have any name, so they could perfectly be part of the same high speed memory used in caches, but mainly a part of the core of the CPU.

_________________
Image http://www.archefire.org/_PROJECTS_/ (udocproject@yahoo.com)

YouTube Development Videos:
http://www.youtube.com/user/AltComp126/videos

Current IP address for hosts file (all subdomains):
190.150.9.244 archefire.org


Top
 Profile  
 
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Mon Jul 17, 2017 2:01 am 
Offline
Member
Member

Joined: Fri Aug 19, 2016 10:28 pm
Posts: 93
~ wrote:
Registers are the minimal set of CPU variables.
I am not sure what you mean here. That is, what "minimal" means in this context. But this could just be a definitional thing.
~ wrote:
Besides that, each register has special tasks defined statically by the CPU core architecture, so they aren't just variables but also have fundamental tasks assigned to them per each instruction and for the general execution.
That is architecture dependent. It may make sense to impose constraints within the ISA for IC optimization, but it is not fundamental property of the register file. For example, the x86 ISA is incapable of indexing its registers through the contents of other registers, but the memory offered in this tier on x86 is too small to be iterated or dynamically managed usefully. So such a logic would be a waste. Yet, I think the lack of proper addressability is not fundamental property. In my opinion, the most defining characteristic that registers have is that their contents are managed manually, and not implicitly by association.
~ wrote:
They are part of what defines the machine word size that a programmer is able of gathering in a single fetch or store memory operation.
From a performance standpoint, the granularity of the CPU operations is a complex matter. The machine word size is relevant, but there are other quantities, such as the width of the interconnect bus, the cache line size, the memory burst length, etc, that are not fundamentally tied to the machine word size directly.
~ wrote:
Hard disks have a register file, a set of contiguous registers.

PCI has registers.

VGA has registers.
I wouldn't make parallels with those, as they are similar only in name.
~ wrote:
The FPU has registers.
This is the same problem.
~ wrote:
A cache is probably not intended to hold a persistent record of the execution state, so in one way or another we always end up reserving some sort of registers.
The cache is not, but main memory is, and the cache is just an associative high-performance booster to main memory. So, whatever main memory can do, main memory with cache can do better. Software engineers have less control over the cache's occupancy, but that is the main distinction between caches and an ordinary memory tier - implicit self-management.
~ wrote:
If we see the instructions at the bit level, we can see that the registers, register sizes and memory indexes are just indexes interpreted in a certain addressing mode, they obviously don't even have any name, so they could perfectly be part of the same high speed memory used in caches, but mainly a part of the core of the CPU.
But what is the principle trade off that this introduces?

Actually, after thinking about the RSVP proposition again, another possible advantage in implicitly managed occupancy is parallelism. Namely, the parallelism between the execution of the ALU and the fetches. However, this should also be possible with out of order execution and conventional register-based designs, I think.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 136 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: snijj and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group