Before you all speculate widely, try reviewing the actual product brief. http://download.intel.com/embedded/processors/prodbrief/324535.pdf . In which you will see this is an MCM with an Atom E6xx SoC die and an Altera FPGA die, interconnected by 1-2 PCIe x1 links. It has an amazing 1466 ball grid array package.
It's not clear to me what this level of packaging and integration achieves compared to mounting a (not integrated) E6xx BGA and a separate Altera or Xilinx FPGA BGA onto the main PCB, interconnected by PCIe x1 or perhaps even x4. Then you would get a broader choice of FPGAs -- and perhaps a simpler PCB escape for the two packages compared to one 1466 ball beast.
The advantages of this MCM as stated in the brief include: * reduced board footprint * lower component count * simplified inventory control / manufacturing * single-vendor support
True, but forgive me if I'm not over the moon. The dream of integrated FPGA fabric into a heterogeneous SoC (same die) includes a very low latency and possibly cache coherent interconect between the processor(s) and the FPGA. But here the FPGA is on the other side of a narrow PCIe link. It can't share the Atom SoC's memory hierarchy / DRAM channels very effectively. It is probably a very long latency round trip from x86 software control / registers and L1$ data, to some registers or function units in the FPGA, and back to the x86. So I think of this as more of a super-flexible Atom SoC platform than a dream reconfigurable computing platform.
It's a nice step but I look forward to so much more.
http://www.fpgacpu.org/usenet/fpgas_as_pc_coprocessors.html (1996): "... So as long as FPGAs are attached on relatively glacially slow I/O buses -- including 32-bit 33 MHz PCI -- it seems unlikely they will be of much use in general purpose PC processor acceleration...."
Virtex-II Pro, Virtex-4, and Virtex-5 offered devices with 0, 1, or 2 PowerPC cores. Xilinx once showed die floorplans of Virtex-II Pros with 4 PowerPC cores but if I recall correctly they never shipped such devices.
The latency to the FPGA fabric largely determines what kinds of coprocessing workloads are feasible.
When hypertransport came out, we (FCCM'ers) knew a HT-based lower latency interconnect should be possible. (Though I wouldn't call 75 ns +/- "low" latency -- that's a couple of hundred instruction issue slots, or a bit more than 1 full cache miss.) But DRC has gone and done it. I love the way it (apparently) just drops in and can even use that socket's DRAM DIMMs. Congrats to Steve Casselman and co.
[Tooting my own horn] please see my Circuit Cellar article series at http://fpgacpu.org/xsoc/cc.html:
"The articles present the design and implemention of the XSOC System-on-a-Chip, including the new xr16 pipelined RISC processor core, on-chip bus, bus/memory controller, and integrated peripherals (parallel port, bilevel VGA controller), all in a single Xilinx XC4005XL FPGA, and also describe a port of the lcc4.1 retargetable C compiler, an assembler, simulator, and demos."
Nowadays, with the advent of big FPGAs, Altera and Xilinx system builder products, and Nios and MicroBlaze soft cores, this is more or less "push button".
See my company's FPGA CPU News site, and my three part (March-May 2000) Circuit Cellar series, Building a RISC CPU and a System-on-a-Chip in an FPGA and the accompanying
XSOC/xr16 Kit, which includes schematic and Verilog versions of the processor, SoC, as well as C compiler (based upon lcc), assembler, simulator, specs, docs, test suites, demos, etc.
There's also an FPGA CPU mailing list, with almost 500 subscribers.
Send mail to fpga-cpu-subscribe@yahoogroups.com to subscribe.
Many of us FPGA CPU hackers also frequent comp.arch.fpga on Usenet.
"I used to envy CPU designers, those lucky engineers with access to expensive tools and fabs. Now field-programmable gate arrays make custom processor and integrated system design accessible to everyone. These days I design my own systems-on-a-chip, and it's great fun."
It's more accessible than some of the other responses would lead you to believe. The tools are quite good, and the devices themselves project a simple synchronous digital world abstraction.
Excellent basic synthesis and FPGA implementation tools are now $0-$55, several proto boards are $100-$200, the devices themselves are $20, and with them you can build 16- and 32-bit processors that run at 33-67 MHz and beyond. Perfect for many embedded systems projects.
Visit our web site, FPGA CPU News [www.fpgacpu.org] for further information. And/or join the mailing list [www.yahoogroups.com/group/fpga-cpu].
See my Circuit Cellar magazine article series, "Building a RISC CPU and a System-on-a-Chip in an FPGA" [www.fpgacpu.org/xsoc/cc.html]. The corresponding free kit (which requires a $100 FPGA proto board from another company) is at [www.fpgacpu.org/xsoc/index.html].
Or see my recent DesignCon'2001 paper on "Building a Simple FPGA-Optimized RISC Processor and System-on-a-Chip" [www.fpgacpu.org/soc-gr0040-001201.pdf]. This latter paper includes the annotated synthesizable Verilog source code of a simple CPU -- less than 200 lines of code.
Learning to design digital systems with a hardware description language, and then progressing to design your own peripherals, and perhaps processors, is not a trivial undertaking, but neither is it anymore an exclusive and unobtainable art, practiced only by high priests in well funded semiconductor companies with in house fabs."
While I have great respect for Mr. Gosling's prolific contributions, clearly this imitation goes both ways. For example:
Microsoft Transaction Server 1.0, shipped 12/96 * automatic transactions for objects, including Java objects * ObjectContexts for automatic services on behalf of objects * declarative transaction requirements e.g. Transaction Requires New * declarative, automatic role-based security, and IObjectContext::IsCallerInRole() * etc.
Enterprise Java Beans, 1.0 final spec shipped 1Q98(?) * automatic transactions for Java objects * SessionContexts for automatic services on behalf of objects * declarative transaction requirements e.g. TX_REQUIRES_NEW * declarative, automatic role-based security, and EJBContext.isCallerInRole() * etc.
The provenance of the ideas behind EJB/J2EE, arguably Sun's most commercially important Java technology, would seem to be revealed in its choice of identifier names.
If you're trying to learn an unfamiliar set of libraries (such as the.NET Framework), the Intellisense feature, and also so-called (context sensitive) DynamicHelp are, well, very helpful.
For example, you declare a variable
Type type;
You type
type.
and Intellisense prompts you with a list of methods on a 'Type'. You *pick* (not type) GetCustomAttributes. You see
type.GetCustomAttributes
You type
(
You get a list of the overloaded methods of Type.GetCustomAttributes, each with return types, parameter lists, and summary descriptions of each overloaded method. You pick the first variant, and it prompts you for args as you go.
Very productive -- no hunting about, and you would have to go out of your way to make an error. The same features work for your code as you write it. Declare some methods, write some summary comments, and sure enough you're prompted with these as you write calls on your own methods. (Apparently) no compile required.
(This feature, while very well done, is not new to VisualStudio.NET, of course. For example, Looking Glass Software's Alice Pascal (1985) had the same type, function, and argument prompting, and context sensitive identifier completion, even for user-defined types.)
That said, when I am writing small amounts of quick and dirty C or Python code I invariably bring up a vi or two.
Try free or $55. See www.fpgacpu.org/index.html#010311
See also my Circuit Cellar 3-part article series, Building a RISC System in an FPGA, at www.fpgacpu.org/papers/xsoc-series-drafts.pdf, and see my DesignCon 2001 paper, Designing a Simple FPGA-Optimized RISC CPU and System-on-a-Chip, at www.fpgacpu.org/papers/soc-gr0040-paper.pdf.
Jan Gray, Gray Research LLC
FPGA CPU News: www.fpgacpu.org
"The problem? If you try to read a paragraph of antialiased text, it just looks blurry. There's nothing I can do about it, it's the truth. Compare these two paragraphs:..."
It's more accessible than some of the other responses would lead you to believe. The tools are quite good, and the devices themselves project a simple synchronous digital world abstraction.
Excellent basic synthesis and FPGA implementation tools are now $0-$55, several proto boards are $100-$200, the devices themselves are <$20, and with them you can build 16- and 32-bit processors that run at 33-67 MHz and beyond. Perfect for many embedded systems projects.
Visit our web site, FPGA CPU News [www.fpgacpu.org] for further information. And/or join the mailing list [www.yahoogroups.com/group/fpga-cpu].
See my Circuit Cellar magazine article series, "Building a RISC CPU and a System-on-a-Chip in an FPGA" [www.fpgacpu.org/xsoc/cc.html]. The corresponding free kit (which requires a $100 FPGA proto board from another company) is at [www.fpgacpu.org/xsoc/index.html].
Or see my recent DesignCon'2001 paper on "Building a Simple FPGA-Optimized RISC Processor and System-on-a-Chip" [www.fpgacpu.org/soc-gr0040-001201.pdf]. This latter paper includes the annotated synthesizable Verilog source code of a simple CPU -- less than 200 lines of code.
Learning to design digital systems with a hardware description language, and then progressing to design your own peripherals, and perhaps processors, is not a trivial undertaking, but neither is it anymore an exclusive and unobtainable art, practiced only by high priests in well funded semiconductor companies with in house fabs.
"On a side note, VC++ was "innovated" by some company that Microsoft bought out, so..."
There's little point asking you to support your claim with evidence because it is Totally False.
You mustn't believe everything you read in those pamphlets the true believers hand out at supermarkets and airports nor in 'excellent briefs' handed out by big trade organizations with big anti-Microsoft agendas...
Before you protest that sometime in the mid-80s Microsoft C 3.0 was OEM'ing Lattice C, or something like that, note that (to my knowledge) there has not been any Lattice C code in MSC since MSC3. (Indeed, a more plausible argument is that all Borland C++ innovation came from its purchase of Wizard C. And all that Symantec C++ innovatation came from Zortech C++ or rather, its precursor, Datalight C.)
(That's the problem with "Microsoft didn't innovate it, they bought it" whining -- it doesn't reflect that a product is 10-15 years evolved with respect to a purhased or OEM'd starter/interim technology, 0% of which lives on in the current product.)
I was there. I wrote a chunk of the MS C++ compiler and other tools. C/C++ 7.0 was a death march and it was a great, great experience. That shipped 4/92. Visual C++ 1.0 followed (2/93). I was there when Scott and Brad and Greg and Dean et al invented ClassWizard and its tight integration with the code editor and the resource editor and MFC.
Bought indeed! Those were the days. The fun we had. Too bad you missed it.
"There was a white glow, overpowering, sublime, running over our island from end to end." -- Churchill
"The Birth of Furby" lecture is on MURL.
on
Autopsy Of A Furby
·
· Score: 1
This fascinating talk by the designer of Furby, Dave Hampton of Sounds Amazing!, is available at http://murl.microsoft.com/LectureDetails.asp?231
Sorry about the marketing. I happen to think conventions *like* COM (I said *like*) are a sensible way to get interop, and besides make sense for writing loosely-enough coupled Component Software [http://www.amazon.com/exec/obidos/ASIN/0201178885 ] (as opposed to Object Oriented Software, which often has scary implementation inheritance couplings and dependencies).
RE: your questions,
Object references between objects in the same context/apartment are direct pointers. Object references crossing contexts/apartments/processes/machines address some kind of proxy-channel-stub structure. The client (object holding the object pointer) usually does not trouble itself with whether it is directly addressing a real object or a proxy, e.g. mostly transparent remoting.
When the client calls a method on an object in the same context, it is a direct C++ virtual function call; when it calls an object in anothe apartment, process, or machine, the proxy marshals the arguments, the marshall buffer is moved to the other address space, and unmarshaled; the object is called, its return values are marshalled, that result is moved to the client's address space and unmarshalled.
(An "apartment" is an object environment within a process, with certain concurrency and thread affinity guarantees, that provides a convenient programming model in a multithreaded application. For example, concurrent calls to objects in a particular single-threaded apartment are serialized. A "context" is an object environment within an apartment, within which groups of objects live. COM+ uses contexts to provide automatic services on behalf of objects, such as automatic security checks and automatic transactions.)
So: near calls are as cheap as C++ calls, and more distant calls can have overhead proportional to the marshaling, copying, and/or RPC overhead.
Some parts of COM involving remote activation and security are privileged, and there's lots of standard code for building proxies and stubs (marshalers and unmarshalers) and so forth from interface descriptions, but you can certainly use your own COM-like conventions for binary interop independent of any OS.
Repeat: you can have binary interop between languages and language implementations without much pain if you keep the kinds of coupling as simple as possible. For example, 1. the only thing you can do with an object is call methods on it (no touching its data members directly); 2. methods can only pass and return objects by reference (pointers, not whole structures); 3. all interoperable implementations produce the same vtable layout from the same interface description.
See also the section "C++ and Portability" in the first chapter, "COM as a Better C++" of Don Box's book _Essential COM_.
In general, it won't happen. Name mangling is just the tip of the iceberg. The different implementations have different object mappings, calling conventions, exception handling tables, etc. It is impossible to agree on names if the code, data, tables, etc. behind the names are not compatible.
For one example object mapping, see "C++: Under the Hood", at http://msdn.microsoft.com/library/techart/jangrayh ood.htm.
Certainly on your particular OS/platform, there may evolve a de facto standard that the various vendors all support.
That said, C++ object mappings are so substantial and intricate, and each vendor's installed base of legacy binaries, objects, and libraries are so difficult to rebuild all at once (assuming separate authorship of components), that each vendor with an installed base is highly reluctant to ever break backwards compatibility with existing object layouts and tables (let alone names). (The flag day problem.) For example, neither the 16-bit nor 32-bit MS object mappings have substantially changed since they were released in 1992 and 1993, except to add new data and tables to support new language features.
If you want interop between implementations, you might consider adopting a binary object interop convention like COM or XPCOM. This requires only that you define a convention for vptr placement and vtable layouts (one convention per platform) and you'll have no naming or other interop problems whatsoever, *and* your components can will interop with components authored in other languages that also expose component intefaces as vptr/vtables.
1. bits not atoms. It's not "chips", it's "hardware designs as represented in HDLs and C++ hardware generators".
2. FPGAs are different. They are $10 to buy and $0 to reconfigure.
3. A RISC CPU is simpler than a Unix kernel. A few experts can design and document a kernel which others can use, extend, and add value. The same thing is true for a RISC CPU design.
4. Open sourced and well documented 33-50 MIPS FPGA RISC CPU designs are coming, and I predict an FPGA CPU will boot Linux before 1/2002, perhaps even before 1/2001. One such CPU won't replace your desktop Linux box, but it will appear in embedded systems. And longer term, there's always MP configurations.
See also http://www.deja.com/getdoc.xp?AN=354667900&fmt=tex t.
Slashdot Mirror
Done: Altera Excalibur EPXA10
In progress: http://www.xilinx.com/technology/roadmap/processing-platform.htm
Before you all speculate widely, try reviewing the actual product brief. http://download.intel.com/embedded/processors/prodbrief/324535.pdf . In which you will see this is an MCM with an Atom E6xx SoC die and an Altera FPGA die, interconnected by 1-2 PCIe x1 links. It has an amazing 1466 ball grid array package.
It's not clear to me what this level of packaging and integration achieves compared to mounting a (not integrated) E6xx BGA and a separate Altera or Xilinx FPGA BGA onto the main PCB, interconnected by PCIe x1 or perhaps even x4. Then you would get a broader choice of FPGAs -- and perhaps a simpler PCB escape for the two packages compared to one 1466 ball beast.
The advantages of this MCM as stated in the brief include:
* reduced board footprint
* lower component count
* simplified inventory control / manufacturing
* single-vendor support
True, but forgive me if I'm not over the moon. The dream of integrated FPGA fabric into a heterogeneous SoC (same die) includes a very low latency and possibly cache coherent interconect between the processor(s) and the FPGA. But here the FPGA is on the other side of a narrow PCIe link. It can't share the Atom SoC's memory hierarchy / DRAM channels very effectively. It is probably a very long latency round trip from x86 software control / registers and L1$ data, to some registers or function units in the FPGA, and back to the x86. So I think of this as more of a super-flexible Atom SoC platform than a dream reconfigurable computing platform.
It's a nice step but I look forward to so much more.
http://www.fpgacpu.org/usenet/fpgas_as_pc_coprocessors.html (1996): "... So as long as FPGAs are attached on relatively glacially slow I/O buses ..."
-- including 32-bit 33 MHz PCI -- it seems unlikely they will be of much use in general purpose PC processor acceleration.
Altera used to have FPGAs with an embedded ARM core + support "stripe" (Excalibur, early 2000s) -- e.g. Altera Excalibur EPXA10.
Of course Xilinx has announced a family of 7 series FPGAs with ARM Cortex-A9MPCore cores. http://www.xilinx.com/technology/roadmap/processing-platform.htm
Both Xilinx and Altera also have in-house soft-processor cores and infrastructure, and ecosystems of third-party soft processor cores.
Many Virtex-II Pro, Virtex-4, and Virtex-5 don't have PowerPC cores. No Virtex-6 or later device does.
Virtex-II Pro, Virtex-4, and Virtex-5 offered devices with 0, 1, or 2 PowerPC cores. Xilinx once showed die floorplans of Virtex-II Pros with 4 PowerPC cores but if I recall correctly they never shipped such devices.
It was done several times, for example, Nuron AcB, Pilchard, and SmartDIMM.
See earlier postings and blog entries on this concept:
s sors.html
http://www.fpgacpu.org/usenet/fpgas_as_pc_coproce
http://www.fpgacpu.org/log/aug01.html#010821-dimm
The latency to the FPGA fabric largely determines what kinds of coprocessing workloads are feasible.
When hypertransport came out, we (FCCM'ers) knew a HT-based lower latency interconnect should be possible. (Though I wouldn't call 75 ns +/- "low" latency -- that's a couple of hundred instruction issue slots, or a bit more than 1 full cache miss.) But DRC has gone and done it. I love the way it (apparently) just drops in and can even use that socket's DRAM DIMMs. Congrats to Steve Casselman and co.
[Tooting my own horn] please see my Circuit Cellar article series at http://fpgacpu.org/xsoc/cc.html:
"The articles present the design and implemention of the XSOC System-on-a-Chip, including the new xr16 pipelined RISC processor core, on-chip bus, bus/memory controller, and integrated peripherals (parallel port, bilevel VGA controller), all in a single Xilinx XC4005XL FPGA, and also describe a port of the lcc4.1 retargetable C compiler, an assembler, simulator, and demos."
Nowadays, with the advent of big FPGAs, Altera and Xilinx system builder products, and Nios and MicroBlaze soft cores, this is more or less "push button".
There's also an FPGA CPU mailing list, with almost 500 subscribers. Send mail to fpga-cpu-subscribe@yahoogroups.com to subscribe.
Many of us FPGA CPU hackers also frequent comp.arch.fpga on Usenet.
You can too.Jan Gray, Gray Research LLC
Also: http://slashdot.org/comments.pl?sid=10374&cid=4519 43:
"I build processors in FPGAs, perhaps you can too
It's more accessible than some of the other responses would lead you to believe. The tools are quite good, and the devices themselves project a simple synchronous digital world abstraction.
Excellent basic synthesis and FPGA implementation tools are now $0-$55, several proto boards are $100-$200, the devices themselves are $20, and with them you can build 16- and 32-bit processors that run at 33-67 MHz and beyond. Perfect for many embedded systems projects.
Visit our web site, FPGA CPU News [www.fpgacpu.org] for further information. And/or join the mailing list [www.yahoogroups.com/group/fpga-cpu].
See my Circuit Cellar magazine article series, "Building a RISC CPU and a System-on-a-Chip in an FPGA" [www.fpgacpu.org/xsoc/cc.html]. The corresponding free kit (which requires a $100 FPGA proto board from another company) is at [www.fpgacpu.org/xsoc/index.html].
Or see my recent DesignCon'2001 paper on "Building a Simple FPGA-Optimized RISC Processor and System-on-a-Chip" [www.fpgacpu.org/soc-gr0040-001201.pdf]. This latter paper includes the annotated synthesizable Verilog source code of a simple CPU -- less than 200 lines of code.
Learning to design digital systems with a hardware description language, and then progressing to design your own peripherals, and perhaps processors, is not a trivial undertaking, but neither is it anymore an exclusive and unobtainable art, practiced only by high priests in well funded semiconductor companies with in house fabs."
See my company's web site, FPGA CPU News: http://fpgacpu.org/
. pdf
/ soc-gr0040-paper.pdf
and my articles: "Building a RISC System in an FPGA":
http://fpgacpu.org/xsoc/cc.html and
http://fpgacpu.org/papers/xsoc-series-drafts
and (simpler): "Designing a Simple FPGA-Optimized RISC CPU and System-on-a-Chip":
http://www.fpgacpu.org/papers
and links: http://www.fpgacpu.org/links.html
"J2EE is not EJB, and the ideas behind J2EE model really have nothing to do with MTS."
Thank you for that correction.
"Imitation is the sincerest form of flattery"
While I have great respect for Mr. Gosling's prolific contributions, clearly this imitation goes both ways. For example:
Microsoft Transaction Server 1.0, shipped 12/96
* automatic transactions for objects, including Java objects
* ObjectContexts for automatic services on behalf of objects
* declarative transaction requirements e.g. Transaction Requires New
* declarative, automatic role-based security, and IObjectContext::IsCallerInRole()
* etc.
Enterprise Java Beans, 1.0 final spec shipped 1Q98(?)
* automatic transactions for Java objects
* SessionContexts for automatic services on behalf of objects
* declarative transaction requirements e.g. TX_REQUIRES_NEW
* declarative, automatic role-based security, and EJBContext.isCallerInRole()
* etc.
The provenance of the ideas behind EJB/J2EE, arguably Sun's most commercially important Java technology, would seem to be revealed in its choice of identifier names.
-- an ex-Microsoft software developer
In June '01, Mike Butts published an independent reimplementation of the xr16 instruction set architecture, written in JHDL.
t ml
4 88
See:
http://www.easystreet.com/~mbutts/xr16vx_jhdl.h
http://www.fpgacpu.org/log/jul01.html#010731
http://groups.yahoo.com/group/fpga-cpu/message/
http://www.fpgacpu.org/#011102
http://www.fpgacpu.org/log/jan01.html#010129
On FPGAs as PC Coprocessors, redux:
http://www.fpgacpu.org/log/aug01.html#010811
On FPGAs as PC Coprocessors (1996):s sors.html
http://www.fpgacpu.org/usenet/fpgas_as_pc_coproce
If you're trying to learn an unfamiliar set of libraries (such as the .NET Framework), the Intellisense feature, and also so-called (context sensitive) DynamicHelp are, well, very helpful.
For example, you declare a variable
Type type;
You type
type.
and Intellisense prompts you with a list of methods on a 'Type'. You *pick* (not type) GetCustomAttributes. You see
type.GetCustomAttributes
You type
(
You get a list of the overloaded methods of Type.GetCustomAttributes, each with return types, parameter lists, and summary descriptions of each overloaded method. You pick the first variant, and it prompts you for args as you go.
Very productive -- no hunting about, and you would have to go out of your way to make an error. The same features work for your code as you write it. Declare some methods, write some summary comments, and sure enough you're prompted with these as you write calls on your own methods. (Apparently) no compile required.
(This feature, while very well done, is not new to VisualStudio.NET, of course. For example, Looking Glass Software's Alice Pascal (1985) had the same type, function, and argument prompting, and context sensitive identifier completion, even for user-defined types.)
That said, when I am writing small amounts of quick and dirty C or Python code I invariably bring up a vi or two.
Try free or $55. See www.fpgacpu.org/index.html#010311
See also my Circuit Cellar 3-part article series, Building a RISC System in an FPGA, at www.fpgacpu.org/papers/xsoc-series-drafts.pdf, and see my DesignCon 2001 paper, Designing a Simple FPGA-Optimized RISC CPU and System-on-a-Chip, at www.fpgacpu.org/papers/soc-gr0040-paper.pdf.
Jan Gray, Gray Research LLC
FPGA CPU News: www.fpgacpu.org
"The problem? If you try to read a paragraph of antialiased text, it just looks blurry. There's nothing I can do about it, it's the truth. Compare these two paragraphs: ..."
//joel.editthispage.com/stories/storyReader$190
See
It's more accessible than some of the other responses would lead you to believe. The tools are quite good, and the devices themselves project a simple synchronous digital world abstraction.
Excellent basic synthesis and FPGA implementation tools are now $0-$55, several proto boards are $100-$200, the devices themselves are <$20, and with them you can build 16- and 32-bit processors that run at 33-67 MHz and beyond. Perfect for many embedded systems projects.
Visit our web site, FPGA CPU News [www.fpgacpu.org] for further information. And/or join the mailing list [www.yahoogroups.com/group/fpga-cpu].
See my Circuit Cellar magazine article series, "Building a RISC CPU and a System-on-a-Chip in an FPGA" [www.fpgacpu.org/xsoc/cc.html]. The corresponding free kit (which requires a $100 FPGA proto board from another company) is at [www.fpgacpu.org/xsoc/index.html].
Or see my recent DesignCon'2001 paper on "Building a Simple FPGA-Optimized RISC Processor and System-on-a-Chip" [www.fpgacpu.org/soc-gr0040-001201.pdf]. This latter paper includes the annotated synthesizable Verilog source code of a simple CPU -- less than 200 lines of code.
Learning to design digital systems with a hardware description language, and then progressing to design your own peripherals, and perhaps processors, is not a trivial undertaking, but neither is it anymore an exclusive and unobtainable art, practiced only by high priests in well funded semiconductor companies with in house fabs.
Jan Gray, Gray Research LLC
There's little point asking you to support your claim with evidence because it is Totally False.
You mustn't believe everything you read in those pamphlets the true believers hand out at supermarkets and airports nor in 'excellent briefs' handed out by big trade organizations with big anti-Microsoft agendas...
Before you protest that sometime in the mid-80s Microsoft C 3.0 was OEM'ing Lattice C, or something like that, note that (to my knowledge) there has not been any Lattice C code in MSC since MSC3. (Indeed, a more plausible argument is that all Borland C++ innovation came from its purchase of Wizard C. And all that Symantec C++ innovatation came from Zortech C++ or rather, its precursor, Datalight C.)
(That's the problem with "Microsoft didn't innovate it, they bought it" whining -- it doesn't reflect that a product is 10-15 years evolved with respect to a purhased or OEM'd starter/interim technology, 0% of which lives on in the current product.)
I was there. I wrote a chunk of the MS C++ compiler and other tools. C/C++ 7.0 was a death march and it was a great, great experience. That shipped 4/92. Visual C++ 1.0 followed (2/93). I was there when Scott and Brad and Greg and Dean et al invented ClassWizard and its tight integration with the code editor and the resource editor and MFC.
Bought indeed! Those were the days. The fun we had. Too bad you missed it.
"There was a white glow, overpowering, sublime, running over our island from end to end." -- Churchill
This fascinating talk by the designer of Furby, Dave Hampton of Sounds Amazing!, is available at http://murl.microsoft.com/LectureDetails.asp?231
Sorry about the marketing. I happen to think conventions *like* COM (I said *like*) are a sensible way to get interop, and besides make sense for writing loosely-enough coupled Component Software [http://www.amazon.com/exec/obidos/ASIN/0201178885 ] (as opposed to Object Oriented Software, which often has scary implementation inheritance couplings and dependencies).
RE: your questions,
Object references between objects in the same context/apartment are direct pointers. Object references crossing contexts/apartments/processes/machines address some kind of proxy-channel-stub structure. The client (object holding the object pointer) usually does not trouble itself with whether it is directly addressing a real object or a proxy, e.g. mostly transparent remoting.
When the client calls a method on an object in the same context, it is a direct C++ virtual function call; when it calls an object in anothe apartment, process, or machine, the proxy marshals the arguments, the marshall buffer is moved to the other address space, and unmarshaled; the object is called, its return values are marshalled, that result is moved to the client's address space and unmarshalled.
(An "apartment" is an object environment within a process, with certain concurrency and thread affinity guarantees, that provides a convenient programming model in a multithreaded application. For example, concurrent calls to objects in a particular single-threaded apartment are serialized. A "context" is an object environment within an apartment, within which groups of objects live. COM+ uses contexts to provide automatic services on behalf of objects, such as automatic security checks and automatic transactions.)
So: near calls are as cheap as C++ calls, and more distant calls can have overhead proportional to the marshaling, copying, and/or RPC overhead.
Some parts of COM involving remote activation and security are privileged, and there's lots of standard code for building proxies and stubs (marshalers and unmarshalers) and so forth from interface descriptions, but you can certainly use your own COM-like conventions for binary interop independent of any OS.
Repeat: you can have binary interop between languages and language implementations without much pain if you keep the kinds of coupling as simple as possible. For example,
1. the only thing you can do with an object is call methods on it (no touching its data members directly);
2. methods can only pass and return objects by reference (pointers, not whole structures);
3. all interoperable implementations produce the same vtable layout from the same interface description.
See also the section "C++ and Portability" in the first chapter, "COM as a Better C++" of Don Box's book _Essential COM_.
In general, it won't happen. Name mangling is just the tip of the iceberg. The different implementations have different object mappings, calling conventions, exception handling tables, etc. It is impossible to agree on names if the code, data, tables, etc. behind the names are not compatible.
h ood.htm.
For one example object mapping, see "C++: Under the Hood", at http://msdn.microsoft.com/library/techart/jangray
Certainly on your particular OS/platform, there may evolve a de facto standard that the various vendors all support.
That said, C++ object mappings are so substantial and intricate, and each vendor's installed base of legacy binaries, objects, and libraries are so difficult to rebuild all at once (assuming separate authorship of components), that each vendor with an installed base is highly reluctant to ever break backwards compatibility with existing object layouts and tables (let alone names). (The flag day problem.) For example, neither the 16-bit nor 32-bit MS object mappings have substantially changed since they were released in 1992 and 1993, except to add new data and tables to support new language features.
If you want interop between implementations, you might consider adopting a binary object interop convention like COM or XPCOM. This requires only that you define a convention for vptr placement and vtable layouts (one convention per platform) and you'll have no naming or other interop problems whatsoever, *and* your components can will interop with components authored in other languages that also expose component intefaces as vptr/vtables.
1. bits not atoms. It's not "chips", it's "hardware designs as represented in HDLs and C++ hardware generators".
x t.
2. FPGAs are different. They are $10 to buy and $0 to reconfigure.
3. A RISC CPU is simpler than a Unix kernel. A few experts can design and document a kernel which others can use, extend, and add value. The same thing is true for a RISC CPU design.
4. Open sourced and well documented 33-50 MIPS FPGA RISC CPU designs are coming, and I predict an FPGA CPU will boot Linux before 1/2002, perhaps even before 1/2001. One such CPU won't replace your desktop Linux box, but it will appear in embedded systems. And longer term, there's always MP configurations.
See also http://www.deja.com/getdoc.xp?AN=354667900&fmt=te
Jan Gray
www3.sympatico.ca/jsgray/homebrew.htm