It doesnt say on the pages how he reverse engineered it. It would be nice to have a system which emulates a whole machine (ala vmware but open) and then open some ports from the emolation to the real hardware. This way Windows assumes its running on a real machine but you have full snooping on the interface with the hardware. It wouldnt take too long to write a simple x86 emulator for KMD. And a nice tool to decide what areas whould be feed straight through to the real hardware would make it much easier to make drivers for other win only devices. It would also be useful to test the linux drivers but you can allready run linux in user mode.
I wonder how much are they paying to arm to have an ISA licence. It was only recently that there were only three ARM ISA licences awarded. One to Motarolla, one to (the then) DEC and one to the amulet group for the asynchronous ARMs.
The reason they were standardising on ARM is because they wanted to get the software support and the redy made cores. Now that the Alpha engineers are not making arms and the best designs are from over 10 years ago the architecture is not fast enough. The ARM ISA is slowing down and people want even more power in their handhelds. Intel can drive the x86 ISA for a very long time simpley because the size or the power disapation is not an issue. So you can play tricks like decode to RISC and so on but this is not possible on low poer devices. I can feel a new wave if ISAs coming through. The costs of creating new tools chains are so low that it is becoming more cost effective to change your tool chain tham pay out for MIPS and ARM licences.
I stand corrected. I an really disappointed. At least they had the decensy to put a reasonable Gfx processor. Unfortunately the CPU shares the on chip RAM with the video.pic. They could have done something real good with this and built a "real" low power machine reather than just another arm imbedded SoC.
I read both articles and I dont think it is an ARM. I wouldnt be suprised if they did write their own ISA. They have been working with IBM on the micrcores for the playstation 3 and writing a nice low power ISA with MM instructions seems quite likely to me. There are many tools to easily adapt compilers and debuggers to any instrcution sey you like. I suspect it is actually multiple core and controlibly speculative. That way you simply dont waste power but get reasonable performance.
Sadly the battery-wise there haven't been any advances since they were invented. Batteries are still made the same way they allways have been. What we do have a bit more of is ways to keep things cool. Not by heatsinking but by clock gating, automatic clock speed adjustments and asynchronous technology.
It would be nice if sony had another instruction set on these chips. Linux can adapt very quickly to new architecuyres unlike some commercial software. Gcc is especially easy to adapt to new architecture and with tools like KMD you can have a whole compiler assembler debugger withing days reather than starting from scratch.
Its nice that companies now have a choice to make their own chips because the software is portable across architectures.
Well the CPU and DSP have allready been designed in the past. All this project needed to do is the software. My university has a third year student doing ogg vobid decoder for our ARM boards. All that has to be done is to get the original source and replace the IO functions with hand written ones to interact with flash memory reather than files. Then you just load your ELF with a debugger and watch the thing squeak.
This is not rocket science. If the thing was done using proper application specific units and layed and they had to reverse engineer the ogg format then I would be impressed.
Actually they havent any specific hardware and it is just a cpu and a dsp. But specific hardware is very good for your size and power consumption. You consume less power because instead of for example working out a sin function with software you have a piece of hardware to do it. You save on power because youre not wasting it on fetching instructions and running your circuit extra fast and on maybe a little on area as you have just made your memory requirements little smaller.
Currently with ultra low feature size technology and memory for free you can easily get away with just using a simple CPU. After all its cheaper than putting in some effort. But this is a reason why my mp3 player only lasts a couple of hours on an aaa battery.
This isn't that amasing. Firstly this is done using a CPU and a DSP. No ogg specific hardware is mentioned. Secondly the chip isnt even a chip but a FPGA implementation. They can show that it works but mapping it out is another chalange if you want to keep it very power. Basicly what they have done was to pick up a core and stick it on an FPGA then compiled ogg/vobis for that CPU's ISA. Place a bit of a bootloader and something to handle the I/O and its done. No magic.
There was an interview with the guy who invented pacman. It was made for girls and the guy was sitting in a fast food place eating pizza wondering what girls like to do. And the only thing he could think of was eating.
I think we are trying to solve the problem of "How can we get girls intrested in computers?" while its probably as silly as trying to solve the problem of "How can we get boys intrested in playing with dolls?"
They are but they have a php extention and so you have to rename them on your end and if you are mirroring deeper then you have to also update the links.
System/Handel C[++] are languages with two good points.
They allow software engineers to design hardware with minimal training and secondly they allow fantasticly fast simulations. The ultimate system of you feed in an MP3 decoder writen in C and you get a player with software at the other end is years (I think more than 10) away.
C is not a natural language to describe hardware. It creates large slow designs with very little transparency to the generated design. Transparency is important as a small looking piece of C code will generate a large slow design while a larger code will generate a smaller faster design. While trasparency is partly implicit in computer programs (You have a vague idea as to what the compiler will generate from your code) in hardware it is very easy to be well off.
FPGA's are getting more and more popular and powerfull. There are allready numerous CPU designs available and the current methods of creating them (mainly verilog and VHDL) seem to be generating much better results than system C ones.
As for soft computers I really like the idea. I would not be surprised to see some FPGA parts on the next 3d cards or CPUs. They allow hardware structures to replace complex code (e.g. I was trying to write code which effectively can be dome with a piece of CAM. hash tables are just a method of emulating CAM in programs).
To conclude, Yeah C based methods will become more popular but only because menagement like them. They produce appauling designs but as silicon area becomes nearly free and in areas where speed does not matter and you need to do a billion simulation runs to test it then yeah it will show it self more attractive to software engineers trying to do hardware. But at the end of the day this is all cheating. If you want to design hardware you really have to learn what structures there are at the bottom level and only then when you know what your compiler will produce for you can you effectively make use of such languages. If companys can affoard to get proper engineers to make hardware they may fetch some C monkey to do it instead but I think if you want to become one then you are selling your self short.
Re:Like it or not, managers default to commercial
on
What is Open Source?
·
· Score: 4, Interesting
A friend of mine who works at an unnamed Swedish company was very much for open source software, but when his managers were thinking of buying software they allways went for the medium-small sized companies reather than the large sized or open-source. The reason was that if they programs didn't work purfectly they could put pressure for the companies to fix it. If they refused they would bury them in legal threats and colapse the company and move on. Thus not many companies would refuse to fix bugs and solve problems. Interestingly the concept of the company fixing its own problems as they hold the source was just unthinkable. No manager would give themselves more work no matter how much money it would save.
I am plesently suprised that my anti-spam encoded email address still has not been spammed. And even a recent spam study found that only normal email addresses got spam. It wouldnt take much to find and decode most of the simple spam-protected email addresses. And I dont think it would take long for the spammers to detect a system such as this and bypass it, but I dont think they will bother at the current climate. But pretty soon I suspect we will get much cleverer email collecting tools and the problem is going to get to the scale of the virus/anti-virus stage.
Slashdot Mirror
Is it just me or does this ship looks so much like someting out of frontier (Elite). Even the jet of flames from behind it.
It doesnt say on the pages how he reverse engineered it.
It would be nice to have a system which emulates a whole machine (ala vmware but open) and then open some ports from the emolation to the real hardware. This way Windows assumes its running on a real machine but you have full snooping on the interface with the hardware.
It wouldnt take too long to write a simple x86 emulator for KMD. And a nice tool to decide what areas whould be feed straight through to the real hardware would make it much easier to make drivers for other win only devices. It would also be useful to test the linux drivers but you can allready run linux in user mode.
I wonder how much are they paying to arm to have an ISA licence. It was only recently that there were only three ARM ISA licences awarded. One to Motarolla, one to (the then) DEC and one to the amulet group for the asynchronous ARMs.
The reason they were standardising on ARM is because they wanted to get the software support and the redy made cores. Now that the Alpha engineers are not making arms and the best designs are from over 10 years ago the architecture is not fast enough. The ARM ISA is slowing down and people want even more power in their handhelds. Intel can drive the x86 ISA for a very long time simpley because the size or the power disapation is not an issue. So you can play tricks like decode to RISC and so on but this is not possible on low poer devices. I can feel a new wave if ISAs coming through. The costs of creating new tools chains are so low that it is becoming more cost effective to change your tool chain tham pay out for MIPS and ARM licences.
I stand corrected. I an really disappointed. At least they had the decensy to put a reasonable Gfx processor. Unfortunately the CPU shares the on chip RAM with the video.pic. They could have done something real good with this and built a "real" low power machine reather than just another arm imbedded SoC.
Those are fuel cells and not batteries. They still need a few more years before they fit into an two AAA battery remote.
I read both articles and I dont think it is an ARM. I wouldnt be suprised if they did write their own ISA. They have been working with IBM on the micrcores for the playstation 3 and writing a nice low power ISA with MM instructions seems quite likely to me. There are many tools to easily adapt compilers and debuggers to any instrcution sey you like. I suspect it is actually multiple core and controlibly speculative. That way you simply dont waste power but get reasonable performance.
Sadly the battery-wise there haven't been any advances since they were invented. Batteries are still made the same way they allways have been.
What we do have a bit more of is ways to keep things cool. Not by heatsinking but by clock gating, automatic clock speed adjustments and asynchronous technology.
It would be nice if sony had another instruction set on these chips. Linux can adapt very quickly to new architecuyres unlike some commercial software. Gcc is especially easy to adapt to new architecture and with tools like KMD you can have a whole compiler assembler debugger withing days reather than starting from scratch.
Its nice that companies now have a choice to make their own chips because the software is portable across architectures.
Well the CPU and DSP have allready been designed in the past. All this project needed to do is the software.
My university has a third year student doing ogg vobid decoder for our ARM boards. All that has to be done is to get the original source and replace the IO functions with hand written ones to interact with flash memory reather than files. Then you just load your ELF with a debugger and watch the thing squeak.
This is not rocket science. If the thing was done using proper application specific units and layed and they had to reverse engineer the ogg format then I would be impressed.
Actually they havent any specific hardware and it is just a cpu and a dsp. But specific hardware is very good for your size and power consumption. You consume less power because instead of for example working out a sin function with software you have a piece of hardware to do it. You save on power because youre not wasting it on fetching instructions and running your circuit extra fast and on maybe a little on area as you have just made your memory requirements little smaller.
Currently with ultra low feature size technology and memory for free you can easily get away with just using a simple CPU. After all its cheaper than putting in some effort. But this is a reason why my mp3 player only lasts a couple of hours on an aaa battery.
There is also open collector.
In not sure if it will hold for much longer so heres a mirror.
This isn't that amasing. Firstly this is done using a CPU and a DSP. No ogg specific hardware is mentioned.
Secondly the chip isnt even a chip but a FPGA implementation. They can show that it works but mapping it out is another chalange if you want to keep it very power.
Basicly what they have done was to pick up a core and stick it on an FPGA then compiled ogg/vobis for that CPU's ISA.
Place a bit of a bootloader and something to handle the I/O and its done. No magic.
There was an interview with the guy who invented pacman. It was made for girls and the guy was sitting in a fast food place eating pizza wondering what girls like to do. And the only thing he could think of was eating.
I think we are trying to solve the problem of "How can we get girls intrested in computers?" while its probably as silly as trying to solve the problem of "How can we get boys intrested in playing with dolls?"
I just got this terrable urge to rate this insightful.
They are but they have a php extention and so you have to rename them on your end and if you are mirroring deeper then you have to also update the links.
Its allways a pain to mirror php pages
System/Handel C[++] are languages with two good points.
They allow software engineers to design hardware with minimal training and secondly they allow fantasticly fast simulations. The ultimate system of you feed in an MP3 decoder writen in C and you get a player with software at the other end is years (I think more than 10) away.
C is not a natural language to describe hardware. It creates large slow designs with very little transparency to the generated design. Transparency is important as a small looking piece of C code will generate a large slow design while a larger code will generate a smaller faster design. While trasparency is partly implicit in computer programs (You have a vague idea as to what the compiler will generate from your code) in hardware it is very easy to be well off.
FPGA's are getting more and more popular and powerfull. There are allready numerous CPU designs available and the current methods of creating them (mainly verilog and VHDL) seem to be generating much better results than system C ones.
As for soft computers I really like the idea. I would not be surprised to see some FPGA parts on the next 3d cards or CPUs. They allow hardware structures to replace complex code (e.g. I was trying to write code which effectively can be dome with a piece of CAM. hash tables are just a method of emulating CAM in programs).
To conclude, Yeah C based methods will become more popular but only because menagement like them. They produce appauling designs but as silicon area becomes nearly free and in areas where speed does not matter and you need to do a billion simulation runs to test it then yeah it will show it self more attractive to software engineers trying to do hardware. But at the end of the day this is all cheating. If you want to design hardware you really have to learn what structures there are at the bottom level and only then when you know what your compiler will produce for you can you effectively make use of such languages. If companys can affoard to get proper engineers to make hardware they may fetch some C monkey to do it instead but I think if you want to become one then you are selling your self short.
Colud someone add a mirror or two because it is currently sucking 100MB/min here and the sysadmins won't look kindly upon it.
There are mirrors of photos, dumps and the original site.
Its allready a red planet.
It starts Saturday, 28th June 0:00 GMT. As the time zone hints, this year it is organized in Sweden.
GMT, (Greenwich Mean Time) -> Sweden?
Greenwich is in Sweden?
A friend of mine who works at an unnamed Swedish company was very much for open source software, but when his managers were thinking of buying software they allways went for the medium-small sized companies reather than the large sized or open-source. The reason was that if they programs didn't work purfectly they could put pressure for the companies to fix it. If they refused they would bury them in legal threats and colapse the company and move on. Thus not many companies would refuse to fix bugs and solve problems.
Interestingly the concept of the company fixing its own problems as they hold the source was just unthinkable. No manager would give themselves more work no matter how much money it would save.
I am plesently suprised that my anti-spam encoded email address still has not been spammed. And even a recent spam study found that only normal email addresses got spam.
It wouldnt take much to find and decode most of the simple spam-protected email addresses. And I dont think it would take long for the spammers to detect a system such as this and bypass it, but I dont think they will bother at the current climate.
But pretty soon I suspect we will get much cleverer email collecting tools and the problem is going to get to the scale of the virus/anti-virus stage.