Thanks for the info :alright:
Thanks very much for the info! :)
64 bit is already with us on later x86 hardware and it has been since MMX. Demand over time will bring in general purpose 64 bit instructions and whewn the economy of scale is correct, many more people will use that type of hardware and code.
Its probably fair to say that when the capacity exists, average commercial software development will find a way to use it. Not that long ago a 1 gigabyte HDD was a big deal, now VOB files are that size and you need a number of them for a movie.
I wonder when the first "Hello World" to use a full gigabyte will be written. RAD vendors will probably make that possible soon. Your "Hello World" app will have smellovision enabled, image heat sensing and production, multiple worlds running in real time and direct email facilities with the Mars colony.
In the mean time, 32 bit x86 will be with us for some time to come as it does most things for most people OK and the lag time to bother to buy a new one will enforce it.
Randy,
The 1024 BYTE processor will be genuine fun.
Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Its probably fair to say that when the capacity exists, average commercial software development will find a way to use it. Not that long ago a 1 gigabyte HDD was a big deal, now VOB files are that size and you need a number of them for a movie.
I wonder when the first "Hello World" to use a full gigabyte will be written. RAD vendors will probably make that possible soon. Your "Hello World" app will have smellovision enabled, image heat sensing and production, multiple worlds running in real time and direct email facilities with the Mars colony.
In the mean time, 32 bit x86 will be with us for some time to come as it does most things for most people OK and the lag time to bother to buy a new one will enforce it.
Randy,
The 1024 BYTE processor will be genuine fun.
mov esi1k, source
mov edi1k, destination
mov ecx1k, loopcount
rep movs1k
Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
And BTW
are there any gals here doing 64 bit assembly? :grin:
are there any gals here doing 64 bit assembly? :grin:
jorgon, some info about Win64.
1024 BYTE
Then a processor with variable word lenght will be really amazing .. if posible (not with the actual structure sure......) eg, can acept tanslate 8 binary digits to 8*1024 acord to what you whant...., also have modifications to himself on the fly, not only adaptative programs, but adaptative architecture ;)
When I do some of this I will tell you :P
Have a nice day or night.
bitRAKE
Thanks, interesting - but worrying that XP64 must use 64-bit drivers.
jorgon, some info about Win64.
Thanks, interesting - but worrying that XP64 must use 64-bit drivers.
For those interested in the Reverse Engineering topic of Itanium Executables:
"Unscheduling, Unpredication, Unspeculation: Reverse Engineering Itanium Executables"
by Saumya Debray et al.
http://bib.universitas-virtualis.org/go.php?id=bibuv-gdl-publ-2003-saumyadebr-3
or alternative:
http://www.cs.arizona.edu/people/debray/papers/revengg-ia64.ps
and before the flames start... this has nothing to do with cracking.
Proof yourself if you think this publication is useful.
"Unscheduling, Unpredication, Unspeculation: Reverse Engineering Itanium Executables"
by Saumya Debray et al.
http://bib.universitas-virtualis.org/go.php?id=bibuv-gdl-publ-2003-saumyadebr-3
or alternative:
http://www.cs.arizona.edu/people/debray/papers/revengg-ia64.ps
and before the flames start... this has nothing to do with cracking.
Proof yourself if you think this publication is useful.
Thanks, interesting - but worrying that XP64 must use 64-bit drivers.
Why? Wouldn't it be a bit sucky to run something as critical as drivers in legacy mode?
Why? Wouldn't it be a bit sucky to run something as critical as drivers in legacy mode?
From what I can gather, when running a 64-bit OS the AMD64 can run a 32-bit prog naturally (not legacy mode). But I was concerned that 64-bit drivers will not be available for some add-on hardware = problems.I am currently assuming WOW64 would also cover the drivers, or there would be some comparible 32-to-64 interface for drivers; but only supporting 64bit drivers would be the way of MS and its partners.
Hm, it's been a while since I read about the AMD64, and I think it was a third-hand source, and I didn't read it all that closely - but I got the impression running 32bit apps when the CPU is in 64bit mode was somewhat akin to 16bit VM86 on normal IA32, and would run somewhat slower?
But you're right that some drivers might not be upgraded for 64bit... too bad, I guess. Then again, as things are now I'm not too interested in 64bit arch for desktop computers. If I did put together a 64bit system, I guess it would be for high performance, and then I probably wouldn't run hardware that was so legacy it doesn't provide native drivers? Dunno.
But you're right that some drivers might not be upgraded for 64bit... too bad, I guess. Then again, as things are now I'm not too interested in 64bit arch for desktop computers. If I did put together a 64bit system, I guess it would be for high performance, and then I probably wouldn't run hardware that was so legacy it doesn't provide native drivers? Dunno.
Then a processor with variable word lenght will be really amazing .. if posible (not with
i once thought of a processor seeing memory only as a bits field, loading words of variable bit size from any bit offset... why? i dont know, but i think i could find interesting uses for it...
theres a problem when accessing a word in an array if the word size isnt a power of two, you ve got to do a mul...
To the Ineffable All,
A variable word CPU is ground that has been thoughly and thoughly plowed and seeded earlier. It is the now very obsolete IBM 1440 system. I know someone who used to program on that machine with Autocoder, IBM's assembler for that hardware. Here is a quote from one of the two links below. I remember my acquaintance saying that it was easy to divide long numbers of arbitrary length. The words were delimited by word marks, but it was hardware limited as to the number of word marks that could be used at one time. Some programming operations could be coded ridiculously easy, but overall it appears the fixed length word machines won out. Ratch
http://msdn.microsoft.com/msdnmag/issues/1200/ednote/default.aspx
http://www-1.ibm.com/ibm/history/exhibits/mainframe/mainframe_2423PH1440.html
A variable word CPU is ground that has been thoughly and thoughly plowed and seeded earlier. It is the now very obsolete IBM 1440 system. I know someone who used to program on that machine with Autocoder, IBM's assembler for that hardware. Here is a quote from one of the two links below. I remember my acquaintance saying that it was easy to divide long numbers of arbitrary length. The words were delimited by word marks, but it was hardware limited as to the number of word marks that could be used at one time. Some programming operations could be coded ridiculously easy, but overall it appears the fixed length word machines won out. Ratch
http://msdn.microsoft.com/msdnmag/issues/1200/ednote/default.aspx
http://www-1.ibm.com/ibm/history/exhibits/mainframe/mainframe_2423PH1440.html
We had to code in just 0's and 1's, and sometimes we didn't even have 1's! But seriously, I started my career (in 1968) working on an IBM 1440. It was obsolete even then, the SYS/360 having been announced four years earlier.
This particular 1440 had 4000 characters of core memory. It was a word-mark machine; data in memory was delimited with the word-mark bit. So the length of operands was variable, depending on where you had set the word marks (and knowing where you had word marks set was 90 percent of debugging).
Coding was in Autocoder, an assembly-level language. All programs were loaded from cards (even the sort, which took a full tray of cards). There was no operating system. The system I worked on had two removable disk drives (with hydraulic actuators) and no tape drives. It was interesting, but I don't miss it.
This particular 1440 had 4000 characters of core memory. It was a word-mark machine; data in memory was delimited with the word-mark bit. So the length of operands was variable, depending on where you had set the word marks (and knowing where you had word marks set was 90 percent of debugging).
Coding was in Autocoder, an assembly-level language. All programs were loaded from cards (even the sort, which took a full tray of cards). There was no operating system. The system I worked on had two removable disk drives (with hydraulic actuators) and no tape drives. It was interesting, but I don't miss it.
There was at least one computer built with variable bit size - it was a Burroughs machine. I believe it was built when large scale ICs either didn't exist or were in their infancy. So it was a very expensive machine.
It would be an interesting retrocomputing project to resurrect this computer's instruction set or architecture.
There were also several decimal-based machines that had variable word lengths measured in digits. There was typically an extra flag bit that was used to end the number. The flag bit could also double as the negative sign.
If you build it into the instruction set, there is nothing you can't do. If you want an automatically scaling of indexes to a nonpower of two, you just build it in. Just extend the addressing modes to include a field that has a scaling constant. The engineers will need to add a multiplier circuit to the addressing unit, but if you can demand it, they can build it.
It would be an interesting retrocomputing project to resurrect this computer's instruction set or architecture.
There were also several decimal-based machines that had variable word lengths measured in digits. There was typically an extra flag bit that was used to end the number. The flag bit could also double as the negative sign.
If you build it into the instruction set, there is nothing you can't do. If you want an automatically scaling of indexes to a nonpower of two, you just build it in. Just extend the addressing modes to include a field that has a scaling constant. The engineers will need to add a multiplier circuit to the addressing unit, but if you can demand it, they can build it.
Actually I am not thinking in a hardware think, but in a evolutionary thing. mmm Maybe a bio-thing ...
Also talking about the bio-thing, is not necesary that is composited by biomass, maybe a lot of little robots (called nanobots??), they do a thing, but if they see is necesary, they will change the original look, or reactions..., sorry dont have much time.... to let my mind go....
Have a nice day or night.
variable bit size from any offset.... why?
I find little time a go a thing that is called hufffam serie or some like that... sorry dont remember the correct name, but was from huffman, in this way, you can code the ascii in other way, eg a: 1, b:0, etc, also I think in other more extrange posibilities, you know that a way for see what is in a crypto the most used value, maybe using a variable lenght will be more secure, duno.
Also talking about the bio-thing, is not necesary that is composited by biomass, maybe a lot of little robots (called nanobots??), they do a thing, but if they see is necesary, they will change the original look, or reactions..., sorry dont have much time.... to let my mind go....
Have a nice day or night.