what about redesigning GoASM/tools to a pure 64 bit system?

[publicminx]

why?

because: the standard today is 64 bit
- 32 bit is out and becomes every second more out ...
- there will not be a a new 32 bit standard in the future again. its over ...
- most people who still learns or creates 32 bit stuff wastes their time. in the same time they could learn and create much more relevant stuff...
- (one reason why the assembler community became so small, too slow... java is on 64bit already NOW completely 64 bit, from the newest to the oldest programm!)
- GoASM has a nice design and no big 32-bit userbase. most examples around are for other assemblers which makes GoASM/tools flexible for a consequently redesign
- consequently 64 bit would save energy in developing... no 32-bit bugfixes needed. clearer design...
- less confusing with 32/64bit mixing ...
- more interesting for most newbies ...
- more interesting examples would be created (...
- etc. etc. (i am sure as longer you think about that as more advantages will you find. i see no disadvantages, becuse for the existing code and all other old 32 bit things are already enough assembler availiable)

of course thats all not valid for every individuum, i talk about standard/"masses"/main focus ...
and see that all as suggestions...

what do you think about that?

ps: i would also stop focussing permanently c/pascal/c++...  instead of running behind that (already also dying languages, even it seems not visible) i would combine the advantages of lowest level with the ones of the "highest level" and most modern concepts...
=> java (not just the syntax, thinking in API instead of macros/libs... community/standards instead of single solutions), c#, xml, uml, exceptions, threads, multiprocessor etc.

greetings

[xanatose]

So the suggestion is basically to cripple GoASM into a 64 bit only assembler that cannot do 32 bit code. If the machine can do both. And the assembler already has the 32 bit support. Why remove it?

As of focus on the masses. The masses like abstraction and dislike coding. And thus like java, C# and whatever keeps them as far as possible from the underlying machine. Thus the complete opposite of what an assembler does.

Java is a virtual machine. And thus slower and a different opcode set. If you like an assembler for java, I would suggest to google for jasmin. Java is also propietary (a fact that Google found the hard way with the Oracle lawsuit).

C# is better than java, but still a virtual machine. It also have its own assembler language for its virtual machine. And is also proprietary.

C and C++ on the other hand can be used to build operating systems and libraries for real machines. Linux, Windows, Free-BSD, and part of Mac OSX is build on it. C and C++ are also evolving languages. Specially C++. They are also languages that are not proprietary but from an industry committee.

The reason C, C++ and assembler have stay so long. Is because they try to mimic how the underlying machine works. And adapt to it. Thus you see assembler getting more instructions. You see C getting features of C++, but remaining loyal to what you write is what you get. You see C++ adding exceptions, run time information, function and data abstractions. Instead of going with the hype, C++ add features once is found they are useful.

[donkey]

32/64 is the way to go (I still code mainly in 32 bit and all of my tools are made for it). I do not in any way find the change from one to the other confusing, with the header project and x86 compatibility mode it is virtually seamless and I have many applications that are compilable in either 32 or 64 bit with the changing of a couple of equates (S=4/8, WINVER and WIN64). I see no reason to remove features from the assembler that do not impede coding for either generation of processor. Also, there are a few bugs to be taken care of and some issues with library support that are being looked into.

Instead I believe Jeremy should continue concentrating on runtime conditionals, that is a feature that every GoAsm user supports as far as I know. Last I heard from him the move was going well enough and he should be back at GoAsm in the near future.

[Ficko]

- there will not be a a new 32 bit standard in the future again. its over ...
- most people who still learns or creates 32 bit stuff wastes their time. in the same time they could learn and create much more relevant stuff...

<EDIT>

The wheelbarrow is 3000 years old and we are still using it.

PCs are only a small portion of machines using CPU.

If you choose a CPU for a microwave or a washing machine you don't even think about 64-bit more likely about 8-bit like "80C85".
Even the Mars Pathfinder was happy with its "RS 6000" clocked with 20 MHz because you have to keep power usage on a minimum.

By the decision there are several factors:

1.)   What speed the machine is required to react to input signals.
2.)   How big are the memory requirements
3.)   Price
4.)   Size
5.)   Power consumption
6.)   Heat emission.
7.)   Etc.

Not only:" Let use the fastest, biggest newest hotrod can be acquired on the market. "
Likewise if you wanna carry some cat food bags to your garage you don't use a "Bucyrus RH400". :P

[oex]

- (one reason why the assembler community became so small, too slow... java is on 64bit already NOW completely 64 bit, from the newest to the oldest programm!)

You are comparing ASM to Java?

[clive]

what do you think about that?

How much would you pay for such a system?

[Vortex]

ps: i would also stop focussing permanently c/pascal/c++...  instead of running behind that (already also dying languages, even it seems not visible)...

Pardon my ignorance but how did you arrive to the conclusion that C/C++ are dying languages? ::)

[donkey]

why?

because: the standard today is 64 bit
- 32 bit is out and becomes every second more out ...
- there will not be a a new 32 bit standard in the future again. its over ...
- most people who still learns or creates 32 bit stuff wastes their time. in the same time they could learn and create much more relevant stuff...

There are not many new standards anyway. The 64 bit processors are nothing more than an extension to the 32 bit architecture. They simply expand the address and data size and add a few more registers, beyond that the changes are negligible. For this reason, development in 32 bit is easily transferable to 64 bit since Windows though it supports 64 bit does not actually make much use of it. There are no constants that I know of that are greater than 32 bit (ignoring sign extension), pointers are changed as well as few other minor things but 64 bit Windows is essentially just 32 bit Windows with a bit more elbow room and FAST_CALL.

- (one reason why the assembler community became so small, too slow... java is on 64bit already NOW completely 64 bit, from the newest to the oldest programm!)

Well, that's very misleading. There is not a single Java based program that is 64 bit, just as there are none that are 32 bit or 1024 bit or any native size. That's just not the way Java works. Java is a JIT compiler system and so a program written for it is compiled at runtime into native code on whatever system it is on be it 32 or 64 bit. In other words I can take the exact same Java code and run it through the Win32 or Win64 version of the JIT and it will run on both. So, you're trying to compare apples and oranges here, a JIT compiler cannot be reasonably compared to one that outputs native code in terms of cross compatibility.