Re: from elsewhere, an assembler
- From: "cr88192" <cr88192@xxxxxxxxxxxxxxxxxx>
- Date: Mon, 9 Apr 2007 00:04:26 +1000
"Wolfgang Kern" <nowhere@xxxxxxxxxxx> wrote in message
news:evaokg$j1g$1@xxxxxxxxxxxxxxxxxxxxxxxx
Hello "cr88192",
[..]
How if you help it with formatting ?
ie: have comments at a defined TAB-stop and
use an ALT-";"-Key to tell it's a comment.
errm, I have no intent at this point for any kind of specialized editor.
I see, for plain text-source import this isn't usable,
so your decision for the alternative "|" is just fine.
yes, I added this as well, either will work.
[...about editor]
But if you think into future, you might once add an integrated
debugger and/or other diplaying help-tools, hotkeys, memus or
whatsoever...
Then you'll need your very own GUI displays and controls anyway.
Be aware of cursing yourself for your first decisions later in
the game (talking from own experience yet) when you have to break
your nails just to merge in additional functionality.
for asm?...
people take asm that seriously?...
I guess this is a different perspective from viewing it as simply a good way
of getting from an HLL to machine code...
So my advice here is:
have your final target in mind from the very start.
well, current goal is to get better linking, and maybe working C
compilation.
How many bytes are one "kloc" ?
depends I guess, I never really measured (I use a linecounter typically).
so, checking with the current VM core:
so, for 33785 loc, 700710 bytes, so, on average, about 20740 bytes/kloc,
which is about on average 20.74 bytes per-line.
Often things gotta change on users demand ... :)
note, I still intend this primarily for backend/autogenerated code,
reasoning mostly that assembler now exists in a state of great decline
anymore, ie, where everyone and their dog knows Java, many know C,
and only some know assembler...
You write an assembler? don't expect Java speaking dogs to use it :)
yes, they won't, and even most C people wont.
my C compiler might, and my JIT compilers do, that was the whole reason for
its existance. otherwise, from my POV, there is not much reason to use
assembler directly anymore (not sufficiently portable, the current baseline
more likely being something like C).
I hope you try to write an assembler!
I write it as I write it, with whatever seems to IMO make sense.
an assembler exists as an assembler, since it is the lowest reasonable
level for code generation (one moves up to the level of bytecode,
and is limited to whatever the JIT implements, and one moves lower
than assembler, well then they have an ugly mess...).
Yes, I know.
My short-fast-smart code isn't 'beautiful' in the eyes of HL-coders.
maybe, dunno.
[...]
Yes, the CPU instructions are different for MOVZXb and MOVZXw/d/q
So it sounds logical to add these optional to the syntax.
yeah.
dunno what others have done here, I just noticed that, "oh crap",
the only distinction was a difference in the size of the right-hand
memory operand. my assembler can't handle this one, so I split it off...
I found two redundant (NOP) forms:
.use32
66 0f b7 .. MOVZXw ax,..
.use16
0f b7 .. MOVZXw ax,..
ok.
actually, as it is my assembler also can't handle 3-arg opcodes either
(so
they have been generally ommitted).
??? I couldn't renounce of:
IMUL r,rm,imm
SHLD r,rm,imm
and all other 'dest,src,imm' instructions.
sadly, my assembler at present can't parse/match them.
as it is, making it do so would be a bit of a change...
I have at times considered partly rewriting this part of my assembler
(both the listing-translation tool and the opcode matching),
so that each argument is fully qualified (size and type),
vs as it is where they are only partly qualified (a single 'size' field
is used for the whole opcode).
in this case, the current size field or similar would probably be reused
as an argument (allowing some 3-oprand forms and funky combinations of
fixed regs and sizes, as found in some opcodes).
I split the whole opcode list into 'one/two/three/block' operator parts
(the inherent CL on shift-double is also a third) and then grouped
it a second time into function-blocks
[ie: |add|..|xor|cmp|-group: 00..05,...,38..3d,80,81,83
|test|neg|not|inc|dec|...|: F6,F7,FE,FF
and so on]
This helps for detailed (value tracking) disassembling and for
immediate verbose comment/help as well.
ok.
[ZeroPage Addressing,...]btw:(64-bit mode)
I am not sure, I am not familiar with this one...
Is just a detail on how many 64-bit instruction work.
[about libs...]
ok.
linking would still be needed in producing the lib.
Yes, if the libs contain OS-specific API calls.
My (lib)modules are just OS-extenders which add functions to it
without using other API functions.
But right, in the windoze world this may not work at all.
yeah.
I have run into a few ugly problems here...
earlier had started a post about it.
realized that there are a few possibly ugly beasts lurking in dynamic
linking, and I am at present unsure how I will deal with them exactly.
as is, they could make things become inflexible and brittle (with annoying
and likely versioning issues, ...). somehow I had failed to take into
account questions like:
what if some code changes in some non-trivial way?
what if a struct changes somewhere?
....
if they crop up, the whole app could break (and I could end up with many of
the same restrictions as with static compilation/linking).
something like this may involve a kind of systematic seperation of concerns
(the same lib is not at the same time both statically and dynamicly linked,
struct changes are a serious matter, ...).
another issue was related to lack of clear info on the gnu version of the
'ar' fileformat...
[about hash]
Can't tell anything as I work the other way around :)
(I type my code on an editable disassembler)
ok.
[about '67']
?... '67'?
mixed 16/32 bit code should work, at least in theory (beat against this
recently, but I am unsure as to whether or not I will ever have much
reason to use this).
The reason can be 'boot-code' and 'BIOS-calls'.
yes, but these are unlikely at present in my current apps (typically
operating purely within the confines of windows, and maybe eventually
linux).
past this, I am much less certain (mixing 64-bit long-mode code with 16
or
32 bit code, could be horrible, dunno what the hell the CPU does here).
As an Author of an assembler you don't need to care :)
this will be the (final user) programmers headache only.
well, yes, to a degree.
or course, it is always possible to simply tell the assembler to use
a different size:
section .text
bits 32 (or .a32)
Don't mixup '.a32'(address override) with 'bits 32'
a32 and .a32 are different directives, the former overriding a single
instruction, and the latter changing the assembler mode (working the same as
'bits 32', since 'bits 32' was actually a more recent addition for possible
improved nasm compatibility).
I'd keep it alive, just in case...yeah. this prefix was borrowed from nasm anyways.
Ok, even the 67 came with 386 :)
ok.
__
wolfgang
I uploaded a new (not topmost) variant of HEXTUTOR
http://web.utanet.at/schw1285/KESYS/HEXTUTOR.zip
added an assorted docs (and a few links) section to my server...
.
- Follow-Ups:
- Re: from elsewhere, an assembler
- From: Wolfgang Kern
- Re: from elsewhere, an assembler
- References:
- from elsewhere, an assembler
- From: cr88192
- Re: from elsewhere, an assembler
- From: Wolfgang Kern
- Re: from elsewhere, an assembler
- From: cr88192
- Re: from elsewhere, an assembler
- From: Wolfgang Kern
- Re: from elsewhere, an assembler
- From: cr88192
- Re: from elsewhere, an assembler
- From: Wolfgang Kern
- from elsewhere, an assembler
- Prev by Date: Re: from elsewhere, an assembler
- Next by Date: Re: cFASM (calling FASM as a C function)
- Previous by thread: Re: from elsewhere, an assembler
- Next by thread: Re: from elsewhere, an assembler
- Index(es):
Relevant Pages
|
