descenterace on 11/12/2005 at 03:02

---

Not true. It is possible to move data from any register to any register. Using the ModRM byte:

ttooorrr

where ooo is the 'reg' operand and rrr is the 'r/m' operand. 'tt' determines the type of the 'r/m' operand; if it's 11, 'rrr' is a register index:

000 - MM0/EAX/AX/AL
001 - MM1/ECX/CX/CL
010 - MM2/EDX/DX/DL
011 - MM3/EBX/BX/BL
100 - MM4/ESP/SP/AH
101 - MM5/EBP/BP/CH
110 - MM6/ESI/SI/DH
111 - MM7/EDI/DI/BH

where the register is determined by the operand size/operation type.

I fail to see why this is ugly. In fact, the segmented x86 architecture is one of the more ingenious and flexible CISC processor designs in existence.


However, it is impossible to transfer from one memory location directly to another without using a register. IIRC, this is a constraint placed upon most CPUs, because it is necessary for the data to pass through the processor at some point. Combining both operations into one would make little sense since the micro-ops would be the same as for the operations necessary for using an intermediate register.



While .NET is a Microsoft invention, it does have certain advantages over Java. These are:
1) The API is better. I hate the way they added Generics (as a seperate part of the API instead of altering the existing data structures) but the .NET API is otherwise better than Java's. For instance, .NET provides sorted structures, unlike Java which provides Collections.sort...() and tells us to make do.
2) Java provides no means of constructing classes and methods from scripts. .NET does. OK, so it's necessary to construct the code within a method via the bytecode, but at least the facility is there.
3) .NET provides a safe typecast (the 'as' operator). In Java, you have to rely upon exceptions.
4) .NET does not force you to handle exceptions. I do not necessarily want to be explicitly forced to handle an InterruptedException. I may want it to be handed up the stack until it forces thread termination. I may want the fact that said exception could be thrown to be hidden from the implementer of the method, so that a method further up the stack can make use of it. And yes, I have indeed found the 'throws' keyword of Java to be a pain in the fucking ass in a recent University project.

If you were calling all GC'd languages unclean... I have to agree on most counts. Because the GC is nondeterministic, the program it is supporting is also nondeterministic (this can be proven, so please can no one object to this; I don't have the time or inclination to explain thread scheduling to anyone) which can make it unreliable if any calls to native code are made.
However, GC'd languages are very nice for prototyping. They also do a very good job if you're writing platform independant code which requires no calls to the native subsystem (such as pretty much anything that can be done in Java; .NET, despite MS claims, was written for Windows and provides a very convenient interface to the COM).

ToxicFrog on 11/12/2005 at 17:55

---

If it worked that way, it wouldn't be ugly. Perhaps this is even possible if you hand-edit the machine code. But NASM and the 8086 documentation both agree with me on this point.
I have heard some stuff to the effect that most, if not all, of these restrictions were done away with around the Pentium or Pentium 2, which is all well and good, but SS1 has to be able to run on a 486.



I submit that almost anything has certain advantages over Java, because Java is a hideous abomination that should have died quietly before ever being released.
At any rate it was the "Visual Studio" part I was icking at, not the ".NET" part. I think they're both disgusting, but I've hardly used the .NET API at all and thus can't in good conscience offer an informed opinion on it; I have used VS.


Hey, I like GC'd languages in principle, and I use Lua for a lot of stuff. I just don't like Java.

Doesn't everything, fundamentally, make system native calls somewhere? At the very least the VM implementation is going to have a malloc() somewhere, and open(), close(), read(), and write() are also pretty necessary.

ToxicFrog on 11/12/2005 at 21:21

---

Well, in theory it's a nice idea, and I admit that the unified search and build warning/error reporting is very useful. My complaints with it stem from four causes:
- It supports a tiny set of languages and there's no mechanism for adding support for more.
- The actual source editing pane is terribly crippled compared to what I'm used to (NEdit) and lacking in configurability.
- if you're using MSDEV, then by default you're also using CL.EXE, the MS compiler, which sucks. I wouldn't go so far as to say that I'd rather hand-compile my code, but I've considered it.
- it's windows-only.

ToxicFrog on 12/12/2005 at 04:54

---

Try either of the following:


I seem to recall other constraints as well, but I can't find my I8086 reference manual, only the MC68000, and Intel no longer has the older reference manuals on their site AFAICT.
It's also worth noting that, although I'm still having trouble findind I80486 documentation, those restrictions were still in place as of the I80386 at least.
Oh, and you can do memory-to-memory copies, using MOVS; you just need to set an assload of registers to do so.


It's ok for really large projects, although if you're doing any sort of GUI you have to dig up something that isn't AWT or Swing for use with it. But even then I'd prefer C/++ with libSDL or FXTK, or Lua with FXLUA.
For small stuff, though, 90% of the code ends up being glue or fluff. I don't like having to write three pages of imports, class definitions, member declaration qualifiers and library-imposed exception handlers for a program that would be five lines in any other language.
And its string manipulation functions suck, but at least it shares that flaw with C and C++.

descenterace on 23/1/2006 at 11:03

---

The problem is that you have a sucky monitor.

My old 17" TFT did the same thing in Battlefield 1942. It wasn't actually possible for me to play the game because even the menu screen would cause that, and hacking the config files didn't seem to affect anything.