Register for free to join our community of investors and share your ideas. You will also get access to streaming quotes, interactive charts, trades, portfolio, live options flow and more tools.
Register for free to join our community of investors and share your ideas. You will also get access to streaming quotes, interactive charts, trades, portfolio, live options flow and more tools.
On Java Plugin:
From the build instructions it appears that the code is C++ (right up your street I think eh?). I would be interested to know the details - code size etc.
The plugin is loaded into the Mozilla VM space so it may be a fairly easy port - just a matter of marshaling the args.
Yes its the source for the JDK.
It includes source for the Java Plugin in the deploy directory.
Here's the top level doc: (edit: actually I pasted the 6.0 release but the readme for 5.0 is exactly the same except 5 replaces 6)
Introduction
This README file contains build instructions for the JavaTM 2 Platform Standard Edition, v6.0 (JDK 6.0) Java Research License Source Release. Building the source code for the JDK requires a high level of technical expertise. Sun provides the source code primarily for technical experts who want to conduct research, port the platform to new operating systems and hardware, or add enhancements that require access to platform internals. If you are not a technical professional in one of these categories, this release is probably not for you.
Overview
This community source release contains all the source code and makefiles required for building JDK 6.0 for the SolarisTM Operating Environment (hereafter "Solaris"), Microsoft Windows platforms, and Linux. To get the complete community source, you need to download/unzip both JRL source and binary bundles.
The source release has the following top-level directories.
control
The control directory contains the makefiles necessary for building the entire J2SE release, including the Java HotSpot VMs and the runtime libraries, tools and utilities.
hotspot
The hotspot directory contains the source code and makefiles necessary for building the Java HotSpot Client VM and the Java HotSpot Server VM.
motif
The motif directory contains the source code and makefiles necessary for building a 32-bit or 64-bit motif library needed by the Linux JDK.
j2se
The j2se directory contains the source code and makefiles necessary for building everything in the JDK 6.0 except the VMs, including runtime libraries, tools and utilities.
deploy
The deploy directory contains the source code and makefiles necessary for building the Java TM plugin and Java TM Web Start.
The JavaTM Web Start product ships with the JDK 6.0 binary release. The source code for the Java Web Start product is available in a separate Sun Community Source release.
install
The install directory contains the source code and makefiles necessary for building the installers and update technologies for the entire j2se. Building installer workspace is not supported as part of this Java Research License Source Release, so the binary images can only be built instead of the bundles.
Sun Java Source Code here:
http://java.sun.com/j2se/1.5.0/download.jsp
Three up from the bottom
Sun has to provide the plugin to link the browser to Java. I
haven't heard anything on this though Stanley Ho, Java Architect
indicated that they didn't even have a plan for it back around
the beginning of the summer.
Email sent to friend at Sun, I'll see what he can get going.
You may like this:
If you're at all interested in XML there's a high-quality XML toolbox called XMLSpy which is a free download for the home edition:
http://link.altova.com/
Don't be put off by the "spy" moniker. Its actually a very fine piece of professional software that includes DTD, Schema, XSLT. Their professional editions sell for quite a lot of money.
They do have a product called Java which apparently is thriving. I don't know how they make money on it though. Maybe tools or server licenses.
Slightly downbeat terminology for probably the most important language out there!
Java has taken over in most comp sci undergraduate courses. My friend, head of one of the biggest comp sci departments bemoans the fact that he now has to learn Java after all those years of C.
In one of the reviews of Galaxy there were some Java benchmarks. I can't find it now but it did compare 32-bit Java with 64-bit and I was astounded at the difference. I recall the 64-bit Java was about 145,000 while the 32-bit was 50,000.
If you find it again let me know.
Did you get AMD64 Java working with your 64-bit Firefox build?
what changes Sun needs to make to its business model but hasn't.
Seems like Intel, Dell & some analysts have no idea what Sun's business model is. Try reading those reports and work out how Sun makes money. Everyone has the wrong idea - I did too before my recent dinner in SF.
Meanwhile Sun's decision to push ahead with development after the dotcom boom - when Wall St was telling them to layoff all their expertise - is producing results. Let's see Sun has a commanding grip on XML (the data format of next generation communication) and Java (the method set of the communication). Take a look at java.sun.com and see what's coming down the pike.
Didn't Intel just buy a company with expertise in XML?
That's called an across the board product line
Really?
http://www.theinquirer.net/?article=26083
Others are calling it a complete and utter mess. Meanwhile I see no evidence whatever that Intel can design their way out of a brown paper bag.
So the idea that Sun is going down is the wishful thinking at Intel HQ?
Probably Dell's HQ too.
If you took a moment to look at what's really going on out there I think you might be more than a bit surprised. Sun is doing amazing and innovative stuff that is winning it lots of friends.
Intel made a conscious decision to keep the memory controller on the chipset, which has the advantage of flexibility with newer memory standards.
This may have an element of truth in it except one not-so-minor-point. New chipsets and new processors from Intel don't work with the old ones so they are always having to introduce a new chipset and a new processor at the same time.
Its not as though the processor is remaining the same and a new chipset comes along to allow exisiting processors to work with some new memory standard.
I have given up trying to follow Intel's product lines. Its a full time job just understanding what they are selling.
Sun looks really interesting
In the last few months I've had to get acquainted with Java & XML. In doing so I'm really impressed with the focus and vision of Sun.
Where Microsoft has half-heartedly included XML, by making it accessible from only Office 2003 Professional - not Standard or Student - and begrudgingly releasing schema, Sun has taken control of the language (Java) and the data format (XML) of networks.
Anyone who hasn't examined it should take a look at Java 1.5. It seems unbelievably robust. It includes JAXP (Java XML processing) and the Web Services pack - downloadable - includes all the Web services libraries: JAXB; JAXR; JAX-RPC; SAAJ. The tools are excellent.
Even IBM looks a bit lost compared to Sun.
When the Internet boom ended, Sun seems to have carried on developing at a furious pace. Now all the tools are there for a great resurgence.
In my sphere the move to XML is just starting. Sun makes a compelling partner in all this.
Why did Intel fall this far back despite their substantial R&D efforts?. . . But at some point Intel is going to have to ditch its IPF design team.
There, now that makes a lot more sense. Something we can really discuss and all agree on.
It would have been nice to dump segment stuff.
Time to read the manuals. Segment registers are ignored in long mode (except for the highly specialized GS)
Segment registers have to be there in compatibility mode (under a 64-bit long-mode OS) so that legacy software will work.
And of course they have to be there to run boring old X32.
There's a lot more to AMD64 than just adding some registers and making the registers bigger.
Take a look at vol 2 of the AMD manual.
1. 64-bit VM (page translation)
2. Interrupt handling (IST) & task priority
3. New RIP addressing mode
4. Better orthogonal handling of legacy registers (8-bit addressing of SIL, DIL, BPL, SPL)
5. NX mode
6. Page Global
There's a few I can think of straight away.
Doing all these changes while preserving, and enhancing 32-bit, in the context of the legacy-heavy 32-bit x86 is a great achievement. People talk about how cell-type processors are oh-so fast etc etc and how easy it was to extend other processors. That's a load of bunk. x86 is highly complex and carries a lot of baggage, even those damn segment registers have to be accomodated! Cell-type processors are fast and straightforward because they don't have all the features of x86.
Are you seriously telling me that the idea of extending the 32-bit registers of x86 to 64-bit and doubling the number visible to the programmer somehow shocks and amazes you?
Mmmm you don't even understand enough to recognize the issues.
That was the trouble with the AMD salespeople that night - they didn't realize what a big deal it was. Only after the meeting when a bunch of people came up to me did I see the penny dropping. I mean the sales people had been to their sales meetings and been told but they didn't understand it and how big a deal it really is.
For an intel promoter you're very unimpressive. More of a sales type I think.
I give them credit for taking the risk, but the simplicity in extending x86 to 64-bits deserves neither applause for innovation nor masterful planning.
Well I can say this two ways.
1) You've got your head up your you-know-where
2) Brilliant, elegant solutions normally look simple and easy in retrospect.
As for none of the features they implemented were firsts for the industry nor ideas that no one else had considered. Really? Well I've been in this industry for a long time (and I'm still in regular touch with comp.sci and electronics researchers who I worked with) and I NEVER saw anything like AMD64 coming down the pike. In fact if you read McGrath's and Weber's account of AMD64 came to be there were a number of "Oooo & aaah" moments as details fell into place.
When I attended an early post-launch Opteron presentation by AMD and there were 300 computer professionals in the room I can honestly say that none of them had an inkling of what AMD64 was. I stood up and congratulated the AMD sales people on their engineer's brilliance and it was EVEN NEWS TO THEM!
I sat with a senior Fedex IT manager in Pheonix one evening in Nov 2003 and explained Opteron & AMD64 to him and he was stunned.
So I think you're just about as 100% dead wrong as someone could be, 180 degrees out of sync with reality. And a buffoon for believing what you wrote.
DCT
I know the algorithm for a DCT and I have all my source code here. Its a matter of knowing the i/f specs in the Mozilla code (i.e how the params are passed and how the code is registered).
So if you can just grab the file and let me know I'll make a stab at it.
Yes my stuff was all done in floating point because that saves steps of adjusting for rounding errors. This way it was just as fast as the integer code but absolutely accurate to the JPEG standard.
Cheers (It'll take the edge off of the XML I'm working on now)
"JPEG decoding with Huffman, Inverse Discrete Cosine Transform"
I've written a number of Inverse Discrete Cosine Transform" routines. If you point me to the code I'll recode them for AMD64. I was meaning to do it anyway and I just got the ml64 assembler.
I would expect a doubling of performance if its coded right - I mean I really know this code! The problem is the register pressue and the pipeline getting full, that and memory access.
Anyone using SCSI?
Came across a registry entry that affects a lot of SCSI host adapters and it removed a bottleneck in my Win 2000 SCSI subsystem, really improved performance. Look up MaximumSGList on Google.
Seems that drives got a lot faster and the software drivers used a rather lowly default for how much could be transferred on a single chunk. By changing the value of MaximumSGList I upped to "quantum" from 64K to 256K and saw a huge difference.
Sun Galaxy Servers
Response to private email from Chipdesigner - I can't do private replies, not being a preminum member.
The guy from Sun I talked to was quite dismissive about actually launching the Galaxy servers, i.e its the wrong question. I think they see the launch in three stages:
1) Offsite contracts - hardware is ofsite and managed by Sun technicians (late-stage validation phase)
2) Onsite installation to existing customer base
3) Launch
Obviously 3) will be supported by testimonials from 2) and that takes a few months, at least. We seem to have been in 1) since March. I suspect phase 2) is currently happening. Maybe the GM deal has something to do with it.
Keith:
Did you read this?
http://www.siliconinvestor.com/readmsg.aspx?msgid=21543920
Isn't that exactly what I told the thread months ago?
Sun - NSG
Compare the following news with the details I posted on Sun some months back. I think the Reg has got Fowler's first name wrong (but Jim may be a nickname).
http://www.theregister.co.uk/2005/07/19/sun_subscriptions/
Now I hope you see why the Sparc & the Opteron nature of Sun looks like a split personality from the outside but internally the two products represent different divisions of Sun and NSG is all Opteron.
Java 1.5.0_04-b05 AMD64 goes final
"With the release, J2SE support for Windows 64-bit has progressed from release candidate to final release. This version runs on AMD64/EM64T 64-bit mode machines with Windows Server 2003 x64 Editions."
http://java.sun.com/j2se/1.5.0/ReleaseNotes.html
For AMD its not about publicity.
I cannot see any settlement that would terminate Intel's business practices that would fit both sides.
As to delays well remember the federal fast-track system is in place. Judges want to see 18-month schedules.
The difference between the Microsoft antitrust case and this case is stark. for one I think AMD waited one helluva long time before filing. I do believe that this has been on the agenda since 2000 - I actually had a conversation with Tom McCoy about it around that time. AMD really waited until it saw the whites of their eyes and until they had a rock-solid case. Plus O'M&M have probably been preparing the case for 2 years+. The discovery plan may be dated 2003 and bound in Morrocan leather!
Where do you see delays measured in years?
As to relief - well the penalties are of the "shall" form so its not up to the judge or jury. 3x actual damages will be a lot of money.
Intel's Success in Court
You think having an extension granted is "winning one in front of the Court"????
To the judge this is a sure sign of weakness. Put yourself in his position. They don't attack the pleadings or provide an answer - why not?
As to your other points:
Seriously I can't help but laugh at your comment "Intel on the other hand, can use the three stooges to win this one". Hmmm, Intel has $16bn in the bank and it purposely chooses a lightweight??? This has to be the most ridiculous argument I have ever heard. I suggest you forward it to Gartner!
Its my suggestion that there are a lot of legal firms in the top ten of antitrust law that wouldn't touch this. Mr Horowitz, lead attorney, is just a local boy to make appearances for the inhouse staff at Intel.
Perry Mason eh? You mean the TV show that violated all the rules of discovery and the Evidence Code. I hope not.
Its not obvious to ask for an extension in time to answer.
Most times a defendant will file a demurrer or a motion to strike portions. That sets up 30 days to the hearing plus another 30, usually, for leave to amend. After the 1st Amended Complaint there's always an outside chance that a judge will try to hose the plaintiff by denying leave to amend - then you're in Appellate.
Intel is playing the weakest form of defense here and it will bolster AMD's case.
Delays are only in Intel's interest when they have a public position which makes sense. That they have, so far, failed to achieve. The longer this goes on the more the OEMs will migrate and ignore Intel's prior threats.
EDIT:
While I was writing this I see that Smallpops posted comments by Gartner (see prior post) Looks to me that Intel agrees with my analysis!
Intel given extension to AMD complaint
http://www.theinquirer.net/?article=24622
Couple of interesting things:
1) I am not impressed with Intel's legal counsel in Delaware (Potter, etc etc). Their lead attorney lacks the experience & gravitas IMHO. Still he's only there doing appearances at present. In terms of experience in antitrust matters this firm is way down the list.
2) Seeking an extension in time to file its answer shows weakness by Intel. Better would have been to attack the pleading IMHO. AMD has siezed the timeline. Now they must keep relentless pressure on. Its quite clear from other sources - letters to OEMs allowing use of AMD products especially - that Intel is sweating buckets. There's a lot of "head-in-hands" stuff going on right now. Intel has no clear response here, there's a lot of flapping around in shallow water without a clear message for the industry in particular. The longer it takes Intel to get its act together and come up with a credible defense the worse it will be for them.
So the watchers are waiting and the longer this goes on the better it is for AMD.
AMD changed its model
From low cost clone supplier to premium parts producer . . and UBS confirmed it when it said they use Opteron servers now. Analysts won't be hanging that stinking fish around AMD's neck anymore.
Q3 guidance
2004 Q3/Q2 growth in CPG was 21%
Q2 2005 CPG sales were $767m. At same growth this leads to $928m CPG sales in Q3.
A profitable Q3 is in the bag. Guidance is for Q3 growth to exceed seasonal patterns.
Looks rather good going forward.
Case law is an excellent place to start discussions.
This approach contrasts with the waste of bandwidth that I've seen on other boards, and Slashdot.
While I think the LePage case is good I anticpate a wealth of caselaw on the Sherman Act violation. Unfortunately this is the most difficult cause of action in the complaint since it requires a finding of monopoly - something that Intel will fight tooth & nail.
I see the Clayton Act as the most bulletproof part of the complaint followed by the Bus & Prof Code.
Looks to me that the Intel compiler allegation is a no-brainer for AMD despite the hundreds of messages on boards everywhere.
The mishmash of responses from Intel & its supporters tells me that their defense is unsure. Right now that are focussing on the damage done to AMD's customer base (cost of retrieving emails). This is twaddle. The channels would like nothing better than to stock both Intel & AMD chips without penalty, that's where the real money lies. Supplying documents is a common part of business - happens everyday with audits etc.
You're missing the point.
It doesn't matter who Intel is selling this to. The fact is that its a deliberate incompatibility.
Read the DDJ article
http://www.ddj.com/documents/s=1030/ddj9309d/9309d.htm
Deliberate Incompatibilities
Well done, nice article. I especially like the legal analysis. This bit:
'I have found that some of the legal literature surrounding the issue of "deliberate incompatibilities" to be fascinating reading. PC-centric readers may well be surprised that many of the issues surrounding Microsoft's travails with the U.S. Federal Trade Commission have been dealt with before in cases involving companies such as Eastman Kodak and IBM. "Deliberate incompatibilities" forms a fairly well-established part of antitrust law, going under monikers such as "non-price predation" and "predatory innovation."'
The fact that the ICCOUT program so easily removes the GenuineIntel check and then the program runs faster on the Opteron is crucial. I see that the test "effectively requiring plaintiffs to prove that the defendant's design had no redeeming virtue for consumers" will readily be met.
Intel Compiler Slug
Question has been asked many whether its actually illegal for Intel's compiler not to allow AMD processors to run the fast code generated by the compiler.
Remember Windows 3.1? Microsoft built in a check to ensure that it wouldn't run properly on DR-DOS, only on MS-DOS.
Caldera sued and won $300m from Microsoft.
I see similarities.
Program to "fix" GenuineIntel check
http://yro.slashdot.org/comments.pl?sid=155593&threshold=2&commentsort=0&tid=142&tid...
Intel Dirty Tricks Affect Benchmarks
So, now we know that the Intel compiler slugs AMD processors. What about benchmark sets?
Well this poster noted that DivX, frequently used by hardware sites, including Toms, was compiled with that same compiler. Did Intel encourage this, was it a "recommended" benchmark program.
So. Tom are you going to rerun the benchmarks? Is DivX going to recompile? Can anyone patch out the cpu_check to return true always for the GenuineIntel compare (its easy really but I don't have an Intel machine to compare).
http://finance.messages.yahoo.com/bbs?.mm=FN&action=m&board=4687810&tid=amd&sid=4687...
Intel Compiler Dirty Tricks & Benchmarks
Interesting read:
http://www.swallowtail.org/naughty-intel.html
Once the GenuineIntel check is patched out the performance dramatically increases on Opterons.
Actually I am anticipating a shareholder lawsuit.
I have only bought AMD processors since the K6-2. This Intel's actions have not done damage to my purchasing of computer parts.
A lawsuit on behlaf of AMD shareholders (current and past) might make a lot of sense.
Very nice pictures of an impressive factory that I actually own quite a part of!
Is it me or do other people agree that the use of a simple "Biro" and pad of paper seems somewhat out of place? And do they really hold steppers together with red & blue duct tape?
Nature of the Semi Biz
So why did Intel do what it did? Answer: the semi biz is characterized by exceedingly high fixed costs. Intel made a decision in the 1990s to expand their manufacturing, adding to the fixed cost.
Their failure to balance fixed cost with technological innovation puts them in a bind. Suddenly all that capacity is concrete waders. Now before the company goes under Intel has to keep producing the revenue stream. The only way out is to do everything possible to maintain sales.
If Intel had not done the illegal things alleged in the lawsuit they would have seem their margins disappear overnight. If the Athlon launch was a nightmare then the appearance of the Athlon64 must have seemed like absolute terror.
In short Intel had no choice.
Interesting legal analysis.
Their legal expert makes little mention of attacks on the pleadings. I would expect Intel's counsel to aggressively try to pare off the causes of action not linked to monopoly status - by jurisdictional arguments on the CA Bus & Prof Code. I can't yet see an attack on the Clayton Act.
There is a possibility not yet made - a summary judgment by AMD. Unlikely since that would be examined de novo by Appellate, i.e the trial court's ruling would be examined afresh by Appellate and probably thrown back. Same goes if Intel moved for summary judgment.
The analysis by Pru assumed that discovery is the critical factor - I think that they have underestimated AMD's planning in this. I have little doubt that AMD has enough already. Overall the analysts treat this as tho' it just suddenly happened. I disagree: this has been simmering for years.
I was talking with a seasoned biz man on July 4. He owns a very large org. When I mentioned O'Melveney & Myers he guffawed and said, "Jeez you don't want to mess with those guys". He knew them very well, even having had offices in downtown LA on the floor below them. Even the very experienced blanche at the prospect of crossing swords with them O'M & M.