OSDev.org

The Place to Start for Operating System Developers
It is currently Wed Aug 23, 2017 2:04 am

All times are UTC - 6 hours




Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 150 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9, 10  Next
Author Message
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Tue Apr 18, 2017 9:15 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 940
Location: Athens, GA, USA
zaval wrote:
dozniak wrote:
zaval wrote:
Or will revive Itanium.


Itanium is not compatible with x86.

for the case of "switching to something new" it's not that bad.


I was assuming that Zaval was making a joke, but apparently not. I don't know enough about the Itanium ISA to really judge, but from what little I saw of it, I wasn't impressed - I had the sense that they were combining a lot of old mistakes with several newer and shinier ones (not new, exactly, since they had already been tried and failed elsewhere, but newer).

I agree with Brendan that a slow migration would be the wisest path for Intel - the only way a new architecture would make sense at this point is if if gave such a dramatic boost in performance that it could emulate the x86 at the equivalent of current speeds (for whatever 'current' happens to be at the time). This worked for Apple in 1989 only because Motorola had done almost nothing to improve the 680x0 series' performance between 1978 and 1988 except increase the clock speed, and the PowerPC chips were already at higher clock speeds than the 68040, meaning that a PowerMac actually could be faster under emulation than a 68040 Mac running native. Trying to do the same with the most heavily optimized chips on the market (even now, the top i7 is faster per core than any of their competitors, though AMD has done a lot of catching up with the Ryzen it still isn't really a match, even if it has much better value for price) is really unlikely to succeed unless a radically new approach arises. Trust me, Subleq isn't nearly radical enough I mean something like quantum computing or something else that throws out the von Neuman and Harvard models out entirely, and possibly even abandons the RAM machine model in general.

As I say, as much as I hate the x86 personally, I really don't see it dying off yet... for reasons Intel doesn't control.

Who could change it? Microsoft, potentially, though they court an uprising if they try. Like Intel, Microsoft had been planning to move away from the x86 since the early 1990s (see the "Advanced Computing Environment" debacle, and the moves to put Windows on Alpha, MIPS, and partially, PowerPC). Despite the talk of 'secure computing' (never a real priority for Microsoft, simply because it was never enough of a priority for the average user so it bought them nothing), the primary reason for .NET is the same as the primary reason for the Java Virtual Machine - it was meant as a lever with which to pry users out of an existing hardware platform (the VAX and the older 386 Sun workstations, going to the Sun SPARC workstations, in the latter case, and from x86 to... something else, in the former).

It hasn't worked out either time. In the Java case, Sun themselves got overwhelmed by cheap PCs which gave a significant portion of the power of their workstations for a fraction of the cost, and they didn't have enough money to keep improving the workstations so even the performance edge was lost soon enough. In the Microsoft case, there simply hasn't been a successor for the x86 which was equal in sheer speed over the past fifteen years, never mind superior. They had their bags packed, but had nowhere to move to, because Intel and AMD could - and had to, in order to stay alive - pour ten times as much money into the x86 ISA as anyone else could for any other one, and no one else wanted a replacement so badly that they could afford to foot the bill.

Things may be changing soon, though. Right now, CPU performance in general has been on a plateau for the past ten years - it has improved, but only by very small increments compared to just the previous five. The limiting factors in performance are now elsewhere - disk access (hence the introduction of Optane and the ever rising popularity of SSDs despite their price), graphics (though that had reached a plateau of sorts as well, until the drive to go 4K gave it greater impetus again), main memory size and speed, and... well, malware.

Seriously, the main thing that hurts Windows (and Mac and Linux, to a much lesser extent due to being lower-priority targets, but still present) is the massive amounts of malicious and intrusive junk that accumulates in every PC starting from the first time it gets on a network. CPU speed can't hope to overcome a tsunami like that. Without constant, intensive maintenance, even the fastest i7 will run slower than an XT after a year of regular Internet use because it will be more clogged with crud than my arteries (and I am a lardball who is pushing fifty).

This means that MS has to be doing some serious thinking about getting a move on. I think that the ARM port of Windows might be for more than just mobile systems - my guess is that they believe that by performing an Apple-esque trapeze act to a new platform, and get more software running .NET rather than any native model, they can unclog their systems (temporarily) and tighten up the control of the platform at the same time. I doubt it will work - they would be throwing the hardcore PC gamers and other high-performance audiovisual users under the bus for at least a few years, and there are just too many legacy programs which they would be screwing over for them to drop x86 emulation, ever - I think it will prove too tempting for them not to try.

Besides, neither gamers nor artists are significant markets for MS, so no real loss there - 'serious' gamers are a tiny sliver of the market, while most musicians, video editors, and artists are on Macs anyway - though the stink it would raise would hurt their PR. They have already been slowly tightening the noose around pre-XP legacy software, so that, too isn't as big an issue as it would have been in, say, 2003.

It would be a band-aid over a sucking chest wound, but it would buy them a couple of years as a fix - and while Microsoft isn't as short-term oriented as most other big corpse-rat cultures, they still think 'strategic long-term planning' is 18 months to two years. It may sound crazy to us engineers and hackers, but given that this approach does seem to be working for them, I will leave it to the MBAs to decide if they have the right of it.

Even if not, that's two more years, and hey, maybe the horse will sing.

But we were talking about Subleq and the affect that overdosing on Hypeocaine has had on Geri's brain, right? Ooh, now with extra Kool-Aid (Bitter Almond flavored, of course)!

_________________
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 Fri Apr 21, 2017 12:57 pm, edited 1 time in total.

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

Joined: Fri Oct 27, 2006 9:42 am
Posts: 940
Location: Athens, GA, USA
Oh, two minor notes regarding the Itanic: first, it was never actually intended for desktop systems, or even workstations - it was, and remains, primarily a server design. They had tentative plans to make workstation versions (HP actually did make one based on it) and eventually migrate it down to the desktop, but that was predicated on it being successful as a server system first. It hasn't been one for the most part, more due to poor marketing, vitriolic corporate alliances that quickly fell apart, and the whole RAMBUS disaster (the initial Itanium 2 chipset, the E8870, was intended to work only with RDRAM, as was the 840 chipset for the Pentium III and the 850 and 860 chipsets for the Pentium 4, and when RDRAM proved to be more expensive, less reliable, and less performant than existing SDRAM, they had to scramble to fix them) than due to any issues with the ISA or CPUs themselves.

Second, they still make them, hence the 'remains' part. There was even a new production series, Kittson, that started getting releases in February of this year, according to Wicked-Pedo. It never took off, but it never actually went away, either, though it probably will soon now that the HP deal has ended.

_________________
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: Wed Apr 19, 2017 3:01 pm 
Offline
Member
Member
User avatar

Joined: Sun Jul 14, 2013 6:01 pm
Posts: 442
from the 97 tons of comments, i have time to react on one, and thats the topic of itanium (which someone obviously mentioned as joke). if we see try to try to abstract the architectures in some form of coordinate system using they complexity, subleq is probably is far of a side, and the another end, there is possibly the itanium. itanium is basically a parody of itself, it had 10x more transistors to show up the same performance as an equivalent x86. in theory, all of they instructions is designed to be very very efficient, but actually no one was able to write proper compilers, a real workload rarely needs for example 3 multiplications directly after each other (and thats why the SIMD units are not so efficient in high level codes aniway, intel should be aware of that). itanium is actually (while its much more complex and non-free than even the x86) meant not for servers, it meant to replace the whole x86, including on desktops. intel also convienced microsoft, and a lot of corporations to sit up on they fanwagoon, and as we seen, they failed miserabely. the conclusion of the story is that having extremely complex instruction sets with vliw and simd will just not solve the issues of computing, and i really hope that nobody will try to emulate that.

_________________
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: Wed Apr 19, 2017 3:32 pm 
Offline
Member
Member

Joined: Mon Jul 05, 2010 4:15 pm
Posts: 478
Geri wrote:
from the 97 tons of comments, i have time to react on one, and thats the topic of itanium (which someone obviously mentioned as joke). if we see try to try to abstract the architectures in some form of coordinate system using they complexity, subleq is probably is far of a side, and the another end, there is possibly the itanium. itanium is basically a parody of itself, it had 10x more transistors to show up the same performance as an equivalent x86. in theory, all of they instructions is designed to be very very efficient, but actually no one was able to write proper compilers, a real workload rarely needs for example 3 multiplications directly after each other (and thats why the SIMD units are not so efficient in high level codes aniway, intel should be aware of that). itanium is actually (while its much more complex and non-free than even the x86) meant not for servers, it meant to replace the whole x86, including on desktops. intel also convienced microsoft, and a lot of corporations to sit up on they fanwagoon, and as we seen, they failed miserabely. the conclusion of the story is that having extremely complex instruction sets with vliw and simd will just not solve the issues of computing, and i really hope that nobody will try to emulate that.


How is it that a company with decades of experience in CPU design and manufacturing comes up with a design like that? What were they thinking?


Top
 Profile  
 
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Wed Apr 19, 2017 3:49 pm 
Offline
Member
Member

Joined: Thu Mar 25, 2010 11:26 pm
Posts: 1801
Location: Melbourne, Australia
OSwhatever wrote:
Geri wrote:
from the 97 tons of comments, i have time to react on one, and thats the topic of itanium (which someone obviously mentioned as joke). if we see try to try to abstract the architectures in some form of coordinate system using they complexity, subleq is probably is far of a side, and the another end, there is possibly the itanium. itanium is basically a parody of itself, it had 10x more transistors to show up the same performance as an equivalent x86. in theory, all of they instructions is designed to be very very efficient, but actually no one was able to write proper compilers, a real workload rarely needs for example 3 multiplications directly after each other (and thats why the SIMD units are not so efficient in high level codes aniway, intel should be aware of that). itanium is actually (while its much more complex and non-free than even the x86) meant not for servers, it meant to replace the whole x86, including on desktops. intel also convienced microsoft, and a lot of corporations to sit up on they fanwagoon, and as we seen, they failed miserabely. the conclusion of the story is that having extremely complex instruction sets with vliw and simd will just not solve the issues of computing, and i really hope that nobody will try to emulate that.


How is it that a company with decades of experience in CPU design and manufacturing comes up with a design like that? What were they thinking?
They were thinking of a new, very complex computing system. The reality of complex systems is very difficult to model without a lot of implementation and I don't see much wrong with what happened apart from the usual marketing hype overstating reality. Many people on this list have complained that Intel have stuck with x86 and yet we also complain when they try something new.

_________________
If a trainstation is where trains stop, what is a workstation ?


Top
 Profile  
 
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Thu Apr 20, 2017 8:57 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 940
Location: Athens, GA, USA
Geri wrote:
but actually no one was able to write proper compilers,


I expect that both the Intel C compiler team and the GCC team would disagree. They both had solid compilers for it before it was actually on the market, and Linux was successfully ported in less than six months. Who didn't have compilers? Anyone who was waiting to see if it would get picked up by anyone other than HP, which was pretty much everyone else - including Microsoft.

Geri wrote:
a real workload rarely needs for example 3 multiplications directly after each other

Actually, it is a very common thing in certain workloads, including things like spreadsheets and graphics.

SIMD is meant for two things: high-performance number crunching, and graphics processing. The move to push video processing (back) onto GPUs, which was just getting going at the time (cycle of reincarnation, yo), made SIMD a lot less useful for desktop and workstation systems, but it was and remains a real boon for HPC - where it is known as 'vector processing' and is absolutely essential for many heavy CPU-bound simulations (OK, real vec proc requires multiple parallel operations, but SIMD is at least a move in the right direction for it). Anything involving large vectors or matrices would benefit from it.

On the desktop? It's pretty much just in spreadsheets, and since you would need either a lot of hand-coded assembly, or a specialized compiler and and a language designed specifically to use the special operations, it probably wouldn't be used even for that initially.

_________________
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 Fri Apr 21, 2017 12:59 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Thu Apr 20, 2017 9:05 am 
Offline
Member
Member

Joined: Mon Jul 05, 2010 4:15 pm
Posts: 478
gerryg400 wrote:
Many people on this list have complained that Intel have stuck with x86 and yet we also complain when they try something new.


Yes, this was my initial thought. x86 is a complex CPU and their goal was to remove some of the out of order complexity and put it into the compiler instead. Despite of this the CPU was still very complex and ran very hot anyway. The Itanium is still very complex and as an example read about its virtual memory system which reminds a little bit of the PowerPC. I consider this type of virtual memory system obsolete, too complex and was invented when CPUs had 128MB of RAM despite it was a 64-bit CPU. The project failed in what they tried to achieve, like the F-35 of CPUs.

There are other CPUs that has a similar approach, Tensilica for example that also has some kind of VLIW version of the CPU. Though their approach is much simpler and probably can be implemented with just a fraction of the gates compared to the Itanium.


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

Joined: Fri Oct 27, 2006 9:42 am
Posts: 940
Location: Athens, GA, USA
Before anyone questions my earlier statement about needing a special language for vector processing: yes, basic forms of automatic vectorization are a thing, but not enough of a thing for this, what with the general problem being NP-Hard and all.

Speaking of which, know what else is probably NP-Hard (assuming that it is tractable at all - I don't know if that has been demonstrated or not but I think it has been)? Optimizing the order of instruction in a UTM. Or anything else that has only a single data-dependent flow of control operation, such as, say, an OISC. Mind you, this applies to RAM machines in general, but having only a single instruction does the compiler devs no favors.

While RISC is generally easier to target than CISC, the main reasons are from orthogonality, regularity, and expanded register files. While OISC is regular to an extreme, it is not orthogonal - it can't be, since all operations look and behave exactly the same. And an OISC has no explicit registers.

In fact, I would be really curious to see just how this C compiler of yours works... C is a really, really good fit for a register machine, but a terrible one for an OISC. Not sure what language would be a good fit for one (something in the Constraint or Dataflow paradigms, maybe, or something for declaratively defining finite state automata), but C (and most of the other Algol family languages) isn't it.

_________________
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 Fri Apr 21, 2017 1:08 pm, edited 3 times in total.

Top
 Profile  
 
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Fri Apr 21, 2017 3:54 am 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 798
Geri wrote:
now, mips.
well i did some investigations with mips. its basically very similar to arm, a little less bloatware, but its prety much influenced by the x86...


MIPS is very different. It's ISA has very few instructions nearly all being very simple and fast in operation. In this aspect it's closer to your beloved subleq than to x86. It's also very regular and is almost free of implicit (hardwired) register operands. Even the stack pointer and the return address registers can be manipulated as any other general purpose register (if/when safe to do so). What's more, MIPS does not have conditional flags set by integer comparing/ALU instructions, unlike ARM or x86. And with MIPS release 6 there are no such flags set by floating point comparing instructions either. Conditional branches check regular registers (for (in)equality with one another or for <=,<,==,!=,>,>= with 0) instead of those flags. What this means is that there are only uniform register dependencies between instructions and so the circuitry can be made simpler and likely cheaper and more efficient. x86 has to additionally track (R|E)FLAGS in order to be able to execute instructions out of order. Btw, there are a few new x86 instructions that do old things but without touching flags. Must be a good thing.

Simpler and fewer instructions are a good thing. Unless taken to absurdly minimalist levels like subleq, where suddenly every primitive operation has to be made up of a series, often quite long, of the same dumb instruction. And these instructions need memory to be stored and probably a big cache. Do you think 16-bit ARM (Thumb, etc) and MIPS (MIPS16e, micro MIPS) modes/ISAs with predominantly short 16-bit instructions exist for no reason? RAM has its non-zero cost. Smaller RAM can be cheap and on-chip. It's a good thing.

Interfacing with outer world is nearly always messy. Because we're using a variety of wildly different peripherals and we need complex control over it. And we often want both compatibility with old stuff (software and hardware) and the ability to use new stuff (software and hardware) without having to throw out our systems every year, which makes things worse. This problem in general is the same with every architecture. There's no architecture that's somehow magically free(r) of it. Let it live and prosper and soon you'll start seeing interesting things in its DNA. Archeologically interesting, that is.


Top
 Profile  
 
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Fri Apr 21, 2017 6:42 am 
Offline
Member
Member
User avatar

Joined: Fri Feb 17, 2017 4:01 pm
Posts: 163
Location: Ukraine, Bachmut
yup, absence of the condition flags was a bit surprising.
Here is a live example of mips32r2 assembly code. For look and feel for the curious. It's from the SEC phase of my FW. This is a function which prints hexadecimal numeric strings into the serial port. The value to print is in $a0 register.
Code:
/* VOID PrintUint32(IN UINT32 n) - prints UINT32 as a numeric string into UART4 */
PrintUint32:
    la    $t0, UART4_BASE
    ori   $t1, $zero, 28      /* nibble shift: 28, 24, 20, 16, 12, 8, 4, 0 */

1:   srlv   $t2, $a0, $t1      /* place printing nibble into 0...3 bits beginning with the most significant one */
   andi   $t2, $t2, 0x000f   /* mask out everything but the printing nibble */

   sltiu   $t4, $t2, 0x0a      /* t2 < 0x0a ? t2=0-9, t4=1 : t2=a-f, t4=0 */
   ori   $t5, $zero, 0x30
   ori   $t6, $zero, 0x37
   movz   $t5, $t6, $t4      /* t5 <- t6 if a-f (t4=0) */
   addu      $t2, $t2, $t5      /* char code adjustment for t2 */

2:   lw   $t4, UART_ULSR($t0)
   andi   $t4, $t4, ULSR_TDRQ
   beq   $zero, $t4, 2b      /* busy wait */
   nop
   sw   $t2, UART_UTHR($t0)   /* writing */

   bne   $t1, $zero, 1b      /* if t1==0 this is the last iterarion */
   addiu   $t1, $t1, -4

   jr   $ra
   nop

_________________
future big goal: ANT - NT-like OS for mips, arm and x86 (and, possibly, ppc and itanium, hehehe).
current smaller goal: efify - UEFI for a couple of boards (mips and arm).


Top
 Profile  
 
 Post subject: Re: How to make an operating system to x86 within a month fr
PostPosted: Fri Apr 21, 2017 1:19 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 940
Location: Athens, GA, USA
Here's a rule of thumb: for hardware CPU implementations, simple instructions operating exclusively on explicit registers, and only load, store, and instruction read operations working on memory, is the most efficient design. In a pseudo-machine (such as JVM), the opposite is true - complex operations with no registers (e.g., a stack machine) work best.

There are exceptions to both, but OISCs aren't among them. The main one right now is, of course, x86, where the complex instructions get broken down, re-merged, re-ordered, and who knows what else by a massively complex instruction pipelining and interpretation mechanism. I am still not convinced that a RISC cannot do better, but right now, none of them do, because no one has any reason to make them better.

Realistically, reconciling either of them into a single model for both native and interpreted code is probably impossible, even for the embodiment of the abstract principle of The Reconciliation of Opposites fnord (don't ask, I don't understand it and never wanted to be it - thanks for the psychological booby prize, Eris!). Reconciling either of them with an OISC is even more daunting.

As an aside, I am in favor of a completely different model than either, one I came up with almost 20 years ago and called RSVP, but I am not sure if a hardware implementation would be feasible. Permit me to post the description:

Me, Myself, and I wrote:
The Reduced State Vector Processor (RSVP)
The current emphasis in CPU design on fast instruction performance is, in the opinion of this author, misplaced. The primary overhead in current software is in I/O and interrupt latency, not instruction execution; most systems today are bound to a slow turnaround in context switching, and are usually idle while waiting for user events. Further, most of the activity in modern systems is bound to processes that involve large vector and matrix calculation, particularly those needed for audio and video processing. While most such work is usually offloaded to DSPs and other co-processors, some still must be handled by the CPU, and the CPU ought to be designed to handle such calculations efficiently.

To these ends, I propose a CPU design meant to minimize processor state, maximize parallel processing efficiency and enhance vector calculations. I call this the Reduced State Vector Processor (RSVP) concept.

The basic concept is to eliminate the majority of the registers in the CPU, replacing them with large (>1M) write-through caches. The processor would have separate caches for code, data and stack, and would have at least two separate caches for each of these functions. The intention is that each process would be allocated a separate cache set, and that in the case of a cache miss, the CPU would automatically trigger a task switch to a process which is in another cache set while the missed cache is updated in background.

All operations would be direct-to-memory, with the ALU operating directly on the caches; in effect, the caches would act as an extremely large register set. This allows the CPU to be reduced to a set of four state registers : Instruction Pointer, Stack Pointer, Frame Pointer and Cache Pointer. Given this minimal state, and the fact that all operations are cached, allows for a single-cycle, single instruction context switch.

As said earlier, the actual calculations are performed directly upon the caches, the ALU has to be able to operate on any section of the cache as needed. Taking this idea further, it can be seen that, logically, the ALU should be bound to the cache it works on, not the CPU, leaving the CPU to perform only the control functions. ALU operations that require more than one cycle should trigger a context switch, just as a a cache miss would, allowing the ALU to operate independently. Further, since it can operate on arbitrary sections of the cache, it should be possible for it to operate on multiple operands, or operands of arbitrary size. This allows for efficient matrix and VLW operations as a natural extension of the ALU design. It should be able, in principle, to operate upon the entire addressable memory; the ALU would call cache refills and continue operating completely independent of the CPU itself.

The final logical step of this design is to add multiple CPUs. Since there are already redundant caches, and the CPU structure is so minimal, it should be possible to have several of these simplified CPUs on a single chip, switching between a large collection of semi-autonomous cache/ALU sets as needed. A reasonable plan, given current chip densities, is a 4 CPU, 8 Cache-set design, which would have a total of 24M of cache memory on-chip. While this is a very large amount of memory, it is well within current densities, and the simplified structure of the processor overall eliminates most of the processor hardware.


My ideas have evolved quite a bit since then, as I was wearing a lemon juice mask on the topic of real-world hardware design at the time (and probably still am).
Image


Despite this, the basic idea - that throughput and task switching were bigger bottlenecks today than sheer processing speed - still seem valid to me. I could, however, be wrong - in fact, I probably am. I know for a fact that this design presents critical, possibly show-stopping, problems in the process management and how the hardware recognizes tasks.

In any case, none of this really matters, because, who the hell is going to spend $5 billion on the silicon wafer development and design work for it? It's the same problem that Geri has, but at least I recognize that it is a problem. He seems to think that a 'simpler' ISA means a simpler and hence less expensive development program, which is absolutely false (in both particulars - it would require a great deal of silicon to implement, and the baked-in costs of new chip development approach or even outweigh the particular design cost in any case - $2 billion is about the opening cost for any new CPU regardless of complexity, because of how ICs are made). Developing silicon for an OISC - any OISC - as a hardware CPU, regardless of performance, would cost as much as the development of a new x86 CPU microarchitecture, if not more - at least Intel and AMD are on familiar ground with that piece of trash.

_________________
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:39 pm, edited 3 times in total.

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

Joined: Tue Mar 06, 2007 11:17 am
Posts: 1006
@Geri: To implement a complex software or hardware machinery, you just need to get fully immersed into that project. If needed, you should spend a whole year just to implement it initially.

And if needed, you SHOULD spend subsequent whole years to add more features, specially for things like an OS, emulator, compiler, or any other major program, specially if you aren't working in a team specifically formed for that very project, but are just a single developer who is learning.


We can always think in terms of implementing the hardware in addition to the OS. In this way we can simplify the OS and build standard hardware that is compatible with the old cards, like sound, network, etc... But we need to learn things like the electronics of the PCI protocol, writing firmware with an appropriate controller, learn electronics (analogic, digital), emulate the MIDI chips with generic controllers with things like the commands a Sound Blaster would expect...

I have managed to implement a good part, practically all 8086 instructions and basic VGA with text mode, 16 and 256-color modes purely in modern binary-capable JavaScript and HTML5 (for canvas, etc...). I did it in maybe 5-6 months, not even a year, so it's possible to learn well a standardized PC architecture, and then maybe (hopefully) implement the motherboards and peripheral cards ourselves, with time and learning:

http://www.archefire.org/Z86Emu/

_________________
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: Sat Apr 22, 2017 4:52 am 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 286
Schol-R-LEA wrote:
There are exceptions to both, but OISCs are among them. The main one right now is, of course, x86, where the complex instructions get broken down, re-merged, re-ordered, and who knows what else by a massively complex instruction pipelining and interpretation mechanism. I am still not convinced that a RISC cannot do better, but right no, none of them do.

Certainly RISC architectures (even when you factor in things like Thumb) have far simpler instruction decoding and pipeline mechanisms. However I guess that this is a price that is mostly paid in additional transistors and not in performance. It is likely that modern x86 implementations perform all diverging instruction decoding paths in parallel in hardware and just AND the result with the current operating mode. I doubt that any of this stuff is done sequentially and negatively impacts performance.


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

Joined: Fri Oct 27, 2006 9:42 am
Posts: 940
Location: Athens, GA, USA
Korona wrote:
It is likely that modern x86 implementations perform all diverging instruction decoding paths in parallel in hardware and just AND the result with the current operating mode. I doubt that any of this stuff is done sequentially and negatively impacts performance.


It's rather more complex than that, actually. A lot more. However, you are basically correct in that a lot of both instruction decoding and instruction performance are don in multiple parallel streams.


I had a different video in mind, but I can't seem to find it. If I do, I'll post it later.

_________________
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 10:12 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 940
Location: Athens, GA, USA
In the meanwhile, here are two things for Geri; I am hoping s/he already knows this, but I figure it is worth getting on the same page about at least the basics.



and


_________________
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  
 
Display posts from previous:  Sort by  
Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 150 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9, 10  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 0 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