Different Implementations of VLIW .
|
Prev: The Mark Thorson FAQ: Read all about this LIAR, BULLY, THUG, CYBERSTALKER and HARASSER
Next: The Mark Robert Thorson FAQ: Read all about this LIAR, BULLY, THUG, CYBERSTALKER and HARASSER
From: Nick Maclaren on 10 Apr 2008 06:26 In article <0e62eb13-3e48-43c3-acf6-f40298097224(a)x19g2000prg.googlegroups.com>, Ripunjay Tripathi <ripunjay.tripathi(a)gmail.com> writes: |> |> I read the first paragraph. I think author should have added about |> VLIW's scope (i.e compile time and random ILP) . If you think |> otherwise can you please tell me that ?? A constructive talk with |> gurus is always helpful to us. The point is that VLIW originated as a way of making direct use of separate hardware units, and was quite commonly used for microcode (e.g. on the IBM System/370 range). It was 'rediscovered' in the 1990s as a way of making use of the 'available' ILP in programs written in 3GL languages (like Fortran or C). Wikipedia has got that arsy-versy. Regards, Nick Maclaren.
From: Ripunjay Tripathi on 10 Apr 2008 06:38 On Apr 10, 3:26 pm, n...(a)cus.cam.ac.uk (Nick Maclaren) wrote: > In article <0e62eb13-3e48-43c3-acf6-f40298097...(a)x19g2000prg.googlegroups.com>,Ripunjay Tripathi <ripunjay.tripa...(a)gmail.com> writes: > > |> > |> I read the first paragraph. I think author should have added about > |> VLIW's scope (i.e compile time and random ILP) . If you think > |> otherwise can you please tell me that ?? A constructive talk with > |> gurus is always helpful to us. > > The point is that VLIW originated as a way of making direct use of > separate hardware units, and was quite commonly used for microcode > (e.g. on the IBM System/370 range). It was 'rediscovered' in the > 1990s as a way of making use of the 'available' ILP in programs > written in 3GL languages (like Fortran or C). > > Wikipedia has got that arsy-versy. > > Regards, > Nick Maclaren. Thanx Nick. The first line I may NOT found in any of the text books. These are the things my foolish questions are searching for. Thanx Again. Regards, Ripunjay Tripathi
From: Anne & Lynn Wheeler on 10 Apr 2008 07:29 nmm1(a)cus.cam.ac.uk (Nick Maclaren) writes: > The point is that VLIW originated as a way of making direct use of > separate hardware units, and was quite commonly used for microcode > (e.g. on the IBM System/370 range). It was 'rediscovered' in the > 1990s as a way of making use of the 'available' ILP in programs > written in 3GL languages (like Fortran or C). among others, 370/168 & 3033 were horizontal m'code (i.e. kind ov vliw). and as mentioned here http://www.garlic.com/~lynn/2008g.html#56 performance of hardware dynamic scheduling ... one of the itanium architects had worked on 370 as well as 801/risc http://web.archive.org/web/20000816002838/http://www.hpl.hp.com/features/bill_worley_interview.html another old itanium article http://web.archive.org/web/20051031092309/http://www.hpl.hp.com/news/2001/apr-jun/itanium.html the "itanium" architect is also credited with dual-address space mode for 3033. the mainstream batch 360 operating system had a heavily ingrained pointer passing paradigm. in moving it to a (370) virtual memory environment, each application was given a 16mbyte virtual address space. However, first half of each virtual address space (8mbytes) contained an image of the kernel. Also, there were many application services that had been done by "sub-systems" outside the kernel ... which also used pointer passing paradigm. In the morph to MVS virtual memory, each of these sub-systems resided in their separate virtual address space. In order to maintain the pointer-passing paradigm, a "common segment" (initially one mbyte) was created in each virtual address space ... where applications could squirrel away paramemters, invoke a kernel call to transfer to a specific subsystem ... passing a parameter pointer. The size of the common segment was actually proportional to the subsystems ... which for larger installations was hitting 4-5mbytes (and growing) ... only leaving 3-4mbytes for actual application use. in the mad rush to get stuff back into 370 product pipeline ... after demise of future system project http://www.garlic.com/~lynn/subtopic.html#futuresys and also recently mentioned http://www.garlic.com/~lynn/2008g.html#53 performance of hardware dynamic scheduling http://www.garlic.com/~lynn/2008g.html#54 performance of hardware dynamic scheduling the 370-xa effort was kicked off ... which was going to take eight years. however, as a stop-gap there was the 303x effort. they took a 370/158 and slightly repackaged it as a 3031 and a 370/168 repackaged as a 3032. The 3033 started out as 168 wiring diagram mapped to faster (& denser chip technology). Initially just using the same circuits per chip, the 3033 would have been 20percent faster than 168. Some last minute design to take advantage of denser circuits/chip in critical areas pushed 3033 to 50percent faster. however, the larger machine would have also met that customers would have run a larger variety of applications and subsystems on the 3033, resulting in the common segment increasing to 8mbytes ... and leaving zero bytes left for applications. 370-xa architecture had a generalized mechanism (access registers) to handle semi-privileged subsystem instruction access to multiple virtual address spaces (eliminating the need for using common segment for stuffing in parameters in support of pointer passing paradigm) as well as new hardware feature that allows direct calls&returns transferring between virtual address spaces (bypassing requirement for call into kernel for processing virtual address space switch). This was independent of 370-xa being 31-bit virtual addressing ... change from 24-bit virtual addressing. However, 370-xa was still several years away ... so a dual-address space mode Q&D subset was rolled out for 3033 (attempting to mitigate common segment growing to 8mbytes and leaving nothing in each 16mbyte virtual address space for applications)
From: HT-Lab on 10 Apr 2008 07:46 "Erik Trulsson" <ertr1013(a)student.uu.se> wrote in message news:47fd4e18(a)news.midgard.homeip.net... > Ripunjay Tripathi <ripunjay.tripathi(a)gmail.com> wrote: >> Different Implementations of the same VLIW architecture may not be >> binary-compatible with each other. >> >> I am looking for explaination on the above line. >> > > > There is nothing special about VLIW in that regard (depending slightly on > exactly which definition of 'architecture' and 'binary-compatible' you > are using.) > > (Exercise 1: Define exectly what you mean by 'architecture') > > (Exercise 2: Write a small program which will behave differently > depending > on if it is running on an Intel 8086 or an 8088. can this be done, and if so how? Thanks, Hans www.ht-lab.com Do these processors belong to > the same architecture according to your definition? ) > > > > > > > -- > <Insert your favourite quote here.> > Erik Trulsson > ertr1013(a)student.uu.se
From: Terje Mathisen on 10 Apr 2008 11:44
Ripunjay Tripathi wrote: > On Apr 10, 4:15 am, Erik Trulsson <ertr1...(a)student.uu.se> wrote: >> (Exercise 2: Write a small program which will behave differently depending >> on if it is running on an Intel 8086 or an 8088. Do these processors belong to >> the same architecture according to your definition? ) >> >> -- >> <Insert your favourite quote here.> >> Erik Trulsson >> ertr1...(a)student.uu.se > > - Architecture scopes all those concepts, that are exposed to > programmer. > - I have not yet wrote such a program, but due to difference in > hardware (In 8086 Carry flag, Parity flag, Auxiliary carry flag, Zero > flag, Overflow flag, Trace flag, Interrupt flag, Direction flag, and > Sign flag) I think there can be certain programs that fail to run in > 8088. Now you are at least looking like you're trying, good for you! However, guessing that the difference between 8088 and 8086 could be in any of the documented registers/flags is totally off the mark. You have to look for tiny implementation differences between those two chips, which after all were built around the exact same core. Terje -- - <Terje.Mathisen(a)hda.hydro.com> "almost all programming can be viewed as an exercise in caching" |