EM64T - A somewhat premature question.

[Apl_and_Asm]

Hello Hutch,

Are you contemplating extension of MASM to 64-bit architectures ?

Regards,

Alain.

[hutch--]

Alan,

Microsoft have a 64 bit version in beta at the moment but its not all that usable yet. Many of our members added to the feedbck by the curect developers at Microsoft to ask that the historical high level syntax be retained and its on the TODO list for 64 bit MASM but not in production yet.

I have not personally lost any sleep over it as 64 bit PC architecture, hardware and OS design is still in its infancy for PCs and there will be a lot of change over time until its a mature technology.

[Apl_and_Asm]

 Hutch,

Thanks for your feedback.
One becomes impatient when reading Intel's manuals or Agner Fog's comparative analysis
of 64-bit OSs in their preliminary versions.
Hardware is always several years ahead of software for obvious reasons, but one can't help
fantasizing about the impact of dramatic architecture improvements on programming.
Be that as it may, we can wait !

Regards,

Alain.
 

[Larry Hammick]

Maybe with the appearance of 64-bit machines, assembly language will move out of the 1950's  :green Assemblers up till now have been essentially filters: files of text go in and a file of machine code comes out. But imagine a table-based assembler, i.e. an assembler built as a database application. Machines are now fast enough and memory is cheap enough to make this feasible, whereas years ago every byte was precious. With a table-based assembler, the programmer won't be editing text files but rather spreadsheets or database tables. In one column he puts the opcode, in other columns the operands, in another column are the machine code bytes equivalent to the whole instruction (filled in by the software as soon as all the symbols, if any, become defined). The software could automatically highlight (say in colour) any symbols that have not yet been defined. Many attempted builds which fail because of a typo or a trivial oversight would thereby be avoided. Linking, and maintaining libraries, would be more efficient too. And maintaining a jumbo symbol table (like windows.inc) would be a snap if its definitions were records in a database rather than mere text lines -- one-click sorting, automatic detection of duplicates, etc.

[rags]

Machines are now fast enough and memory is cheap enough to make this feasible, whereas years ago every byte was precious.

But isn't this already a problem with alot of the new software being released today?
IMHO it seems to me that processor speed and tons of memory, are being used to try to compensate for bloated code and sloppy programming.
Rags

[Ghirai]

IMHO it seems to me that processor speed and tons of memory, are being used to try to compensate for bloated code and sloppy programming.
Rags

Exactly my point.

[Larry Hammick]

>IMHO it seems to me that processor speed and tons of memory,
>are being used to try to compensate for bloated code and sloppy
>programming.
>Rags

I agree. But I meant to say that an assembler can be built which
uses more memory and disk than current assemblers, but which can
assemble small and fast code, for substantial applications, in much less
of the programmer's time than current assemblers.

[zooba]

With a table-based assembler, the programmer won't be editing text files but rather spreadsheets or database tables. In one column he puts the opcode, in other columns the operands, in another column are the machine code bytes equivalent to the whole instruction (filled in by the software as soon as all the symbols, if any, become defined). The software could automatically highlight (say in colour) any symbols that have not yet been defined.

This sounds like an IDE. There's no reason why it couldn't be done already... maybe you've found a project  :wink

[Larry Hammick]

zooba> This sounds like an IDE. There's no reason why it couldn't be done already... maybe you've found a project

If I had the time :( . But it's doable. As the programmer types in some fields, the software calculates others, just as a spreadsheet does. It could be given the functionality of an unassembler as well, and (with enough work) a debugger, all in one. Olly could do it, or maybe Betov.