61–70 of 78 posts
Is there a good Windows assembler that doesn't get flagged by anti-virus software? UPDATE: I just ran across JWAsm and haven't encountered any problems so far. http://sourceforge.net/projects/jwasm/
[1]: http://flatassembler.net/
[2]: http://menuetos.net/
Earlier quoted context omitted.
You can convert it automatically.
How can I without going to the trouble of writing an assembler myself? Anyway, the job is already done.
I learned by working through the software developers' manuals. Many years ago, they used to ship them as physical copies. Nowadays they just send CDs. PDF copies: http://www.intel.com/content/www/us/en/processors/architectu...
When did they stop shipping physical copies? I ordered the new manuals for VT-x not 4 years ago and they were happy to ship me the full set of volumes for free.
Note: We are no longer offering the Intel® 64 and IA-32 Architectures Software Developer’s Manuals on CD-ROM. Hardcopy versions of the manual are available for purchase via a print-on-demand fulfillment model through a third-party vendor, Lulu (please reference 1 and 2 below): http://www.lulu.com/spotlight/IntelSDM.
Intel keeps making up new names for their x86-64 architecture. Now 'x64' did they use that one before? Is IA-32e or EMT64 not better? Also if you want to find out quickly what they mean by 'x64', why is the article tagged with 'ia64' (which means Itanium).
- AMD64 -> Original x86 64bit extension from AMD. - EM64T (EMT64 is a common typo) -> Intel's implementation of AMD64, intel traded SSE3 to AMD for AMD64. - IA-32e -> Same as EM64T, Intel used this name for a bit, mostly during development. - INTEL64 -> Intel renamed EM64T to be more in line with AMD64's naming. - x86-64 -> Overarching instruction set, AMD64 and INTEL64 are implementations. - x64 -> Shorthand for x86…
Why would you do this? Given that you never use 4 GB of memory, you can save a few bytes of memory (32-bit pointers instead of 64-bit) while still getting the extra registers and operations of x86-64 code.
"Intel stores bytes "little endian," meaning lower significant bytes are stored in lower memory addresses." I would like to meet the person that doesn't know what endianness is, but can still understand that explanation.
I agree that prose was not the right way to communicate this; BE & LE are much easier to explain via example (1 -> 00:00:00:01 or 01:00:00:00).
Earlier quoted context omitted.
I always read mov x, y with coma being a synonym for equals, like mov x = y, hence it feels more natural to me. But the biggest issues are address modes, specially the more complex ones and the macros seem very light weight in features when compared to the Intel world.
I love this comment. It shows how powerful the right metaphor can be in understanding something, which is something we obsess over at Dev Bootcamp when teaching students. It also shows how tiny affordances ( http://en.wikipedia.org/wiki/Affordance ) make us "think" specific thoughts. I mean, it's called "mov" so something must be moving, which means there must be a subject, object, and possibly an indirect object, ri…
- read "mov X,Y" as "X = Y"
- adjust syntax so that it allows "X = Y" (what you see is what you think)
- similarly, replace obscure syntax for indexed memory acces by such things as "X = Y[3]"
- getting annoyed with the seemingly random limitations of the language, add an expression parser that translates "X = 2 * Y + 3" into "X = 2 * Y" and "X = X + 3", each of which gets assembled into one instruction. For now, only allow expressions that get away with only using the result register for temporaries.
- use existing macro capabilities to build a library of control flow statements such as IF and WHILE.
- introduce standard way to call subroutines.
- introduce shorthand method for doing such calls: one for the call site that takes a couple of expressions as argument, and one for function entry that uses macros such as 'int' and 'char' to pop arguments from the call stack.
By that time, one almost has K&R C.
That 3D "cross" graphic (Figure 1, "General Architecture") might be the worst illustration of a programmer's model for a CPU I've ever seen. I'm sure it makes sense after you've read the accompanying paragraph a sufficient number of times (once didn't cut it, for me), but not so sure it helps in that understanding. I guess it's a funny hint that the x86's architecture is complex, when a figure that's just trying to d…
I don't think thats the right graphic - a more reasonable graphic is in the PDF which the article is a copy of.
Earlier quoted context omitted.
I love this comment. It shows how powerful the right metaphor can be in understanding something, which is something we obsess over at Dev Bootcamp when teaching students. It also shows how tiny affordances ( http://en.wikipedia.org/wiki/Affordance ) make us "think" specific thoughts. I mean, it's called "mov" so something must be moving, which means there must be a subject, object, and possibly an indirect object, ri…
I see this more as a) an example of how well humans can learn to ignore misdirection (the word 'move' hints at src, dest arguments) and b) the first small step towards C: - read "mov X,Y" as "X = Y" - adjust syntax so that it allows "X = Y" (what you see is what you think) - similarly, replace obscure syntax for indexed memory acces by such things as "X = Y[3]" - getting annoyed with the seemingly random limitations…
There wasn't an Assembly language available as we tend to know.
I don't remember the name of the processor, though.
For those of you that went through Z80, 6502, 68000, x86 macro assemblers like myself, it is just me or does the AT&T syntax just suck? I recently had to convert some code from Intel syntax with NASM macros to GAS with AT&T syntax, and boy what a pain.
I agree that indexing looks way better in Intel ("[ebx+3]") than in AT&T syntax ("2(%ebx)"). However, for me, AT&T's "mov X Y" for "move X to Y" feels better for me than Intel's "mov Y X" for "move Y from X" (who says that?). If they wanted to things in reverse, they should have named the instruction differently, for example as "load Y X" for "load Y from X" (as in "LDA #0xFF" from the 6502) As for movl instead of mo…
If x86 used LD instead of MOV, it would make more sense. LD AX,4 would be read as "load register AX with the value 4"; LD AX,BX would be "load AX with what's in BX"; LD AX,[SI] would be "load AX with what's in the memory location pointed to by SI" and so forth.
Earlier quoted context omitted.
"It shows how powerful the right metaphor can be in understanding something" Just like how I was taught the difference between " ". Our teacher drew the rest of Pac-Man around the " " so that we'd think of " " like the mouth of Pac-Man. It wants to eat the larger number. But that was back around 1983 when Pac-Man was all the rage (when I was drawing Pac-Man eating ghosts on my folders).
My elementary school teachers used a similar metaphor with alligators. But I never could remember which number it was that got eaten, so I just figured the bigger side was for the bigger number. Since an equal sign doesn’t have a “bigger side”, it would imply that both sides are the same. Then I wondered why they didn’t just teach that. Then I liked school even less. (Oddly enough, my childhood intuition about equals…
It took me a long time to differentiate the symbols because, before using the alligator metaphor, my teacher tried this one: cross a line that goes perperdicular to the bottom part of the symbol. If it turns into a 4 it's smaller than; otherwise, if it turns into a 7, then it's bigger than.
I remember seeing a "5 When I hearded the alligator metaphor, however, I got it instantly.