| |
| |
| |
|
Page: 1 2 3 4
Comments:
<0> awesome, i'll try it out
<0> i know nasm has more features than gas but i learned on gas so i was hoping i could use it
<1> just stuff .code16 in front
<1> of the file
<0> yeah, that's what i usually do for real mode code
<0> on >386 processors
<0> i guess >=386
<2> the only real 16bit asm I know is tasm
<0> does nasm not support real 16 bit stuff?
<0> i've never really used it
<1> atp: all unix-related ***emblers generally **** at real mode support... segmentation and all that
<0> yeah
<1> atp: in fact, segmentation will be your big problem with gas...
<0> it would be nice to hack together some extensions to gas to make it not **** in that regard
<1> atp: the sad part is: there is no good way to do it
<0> i really don't know much about 16-bit programming, which is part of the reason i thought it would be fun to play with this old 286
<0> how do you mean?
<2> mwk, that's not quite true. all that works like a charm as long as the cpi supports 32bit wide addressing
<1> well, i don't really see how we could get something better than now
<2> u
<1> segmentation was always a hard issue
<0> syntax-wise?
<2> no. not on gas at least.
<2> I worked a lot on realmode code with gas lately
<1> wobster: is there some sort of %segment(symbol) in gas?
<2> yes. just %es:%di like syntax
<0> i think the big difference is just %es:(%di) instead of [es:di] isn't it?
<1> wobster: but gas doesn't really understand that value of symbol1 should be taken relative to segment1
<1> wobster: which means gas works fine, as long as all that was generated by gas fits in single segment
<2> mwk, but that's true for every code. it's a op limitation.
<2> an
<1> op?
<2> instruction
<1> well, yeah, sort of.
<2> it's a horror :)
<0> it seems to me that gcc can't produce segment aware code, but that if you're hand coding in gas there should be no really problems...
<1> but it'd be nice to be able to specify 'far symbols'
<1> atp: gcc can't produce 16-bit code at all. point is moot.
<0> mwk: it can if you do an inline ***embler call invoking .code16
<0> with certain limitations of course
<0> because gcc just produces code that gets fed into gas
<1> atp: but it'll use 32-bit instructions. yeah, code will be 16-bit, but won't work on your beloved 286.
<2> it's just realmode on a 32bit cpu then. not purely 16bit
<0> right
<0> as for far symbols in gas... isn't that what the l* instructions are for?
<0> lret, lcall, ljmp...
<0> gas ***umes near pointers for all addresses unless you use those ops
<1> well, yeah
<1> but you need to manually do segment management
<1> and if you have several distinct segments, things are getting tricky
<0> forgive my ignorance here, i really know nothing about 16 bit programming, but how do properly segment aware ***emblers deal with this problem?
<1> well, you define a 'segment'
<2> atp, no. in gas you have to specify instruction-trypes manually or it will try to guess those. so suffixing them with l,w,b is encouraged
<1> and you can use something like 'segment of symbol' and 'offset of symbol' and they properly fill out a pair that will work
<0> wobster: that i know, but l, w and b are width parameters, not near/far distinction on addresses
<2> nasm doesn't allow you to specify them and you sometimes run into trouble because of that
<1> wobster: dword [memory reference]
<2> atp, right. that exists no FAR mov, afaik
<1> wobster: and it chokes on ambigous instructions, so it's alright
<2> too wide
<1> but then, it's ugly...
<0> wobster: by far move, you mean moving something into a memory on a segment other than %ds?
<0> wobster: or what?
<2> mwk, sometimes it messes up the code when you're doing really evil hacks
<2> atp, yes. the instruction is prolly to wide then. but that`s just a recall. haven't checked.
<0> i prefer at&t syntax, but i started writing ***embly on non-x86 unix machines (sparcs mostly) and so i guess it's just what i'm used to...
<2> also you're partly limited by the cpu and the ***embler to similar degrees.
<0> wobster: hm, i just did a mov 32, %es:(%di) and gas didn't choke on it
<0> 26C7052000
<0> sorry, that was a movw
<1> atp: EEK. it SHOULD choke on that. isn't '32' a memory reference?
<2> atp, of course. but es%:%si to es%:%di directly won't presumably
<0> my bad, $32
<1> wobster: movsb?
<2> that's not a mov
<0> wobster: does the processer even support that? i thought there was no way to that kind of direct move without an intermidiary
<2> atp, I just said that, didn't I?
<0> wobster, you did, i'm confused, i thought we were talking about limitations in the ***embler rather than in the CPU itself
<0> (ie, that a real 16-bit ***embler designed for say the 286 would have some way to handle these issues)
<0> i'm just trying to figure out what the theoretical shortcomings of gas on 16-bit processors are exactly
<2> atp, anyway, the message is as before. don't waste your time on that. the results are the same on every cpu anyway ...
<1> atp: ****s if you have multiple segments... other than that, it's fine.
<0> mwk: hm, well i guess i'll figure it out :)
<0> segments are sort of neat i think, but that's probably because i've never been forced to program with them
<1> *cough* *barf* *cough*
<1> well... my personal opinion, with my only experience with them being from years ago in my early DOS days, is that they're easy to suffer through after you get used to them
<3> hehe
<1> but flat memory really is better scheme
<0> there seem to be some neat protected mode tricks you can do with segments though... flat mode forces you to only use ring 0 and ring 3
<0> i'm talking 386 here obviously
<2> atp, what are you talking about?
<0> the 286 is broken in that regard... 286 protected mode is a sham from what i've read
<2> no., it's not. it's just a little limited. but I doubt your 286 has more than 16mb of ram
<0> wobster: well, the 80386 programmer's reference manual talks about doing protection on segments
<0> i think this 286 has less than a meg
<0> of ram
<2> ok. it's very limted. but still it`s the same protection model as today
<2> atp, there are ALWAYS segments
<0> no, at least not according to the docs, 286 protected mode is severly broken
<0> poorly designed
<2> that cannot be disbaled. but you can resize them so they span the whole address space
<2> I don't think intel will write in it's own 286 manuals: "hey idiot. this cpu is crap. go buy a motorola"
<0> wobster: i think the idea was that if you put different processes in different segments or something you could have special kernel/userspace hybrid processes that can directly affect memory in rings below them, or something
<2> it's limited by a 20bit wide addressline. that's all
<0> wobster: not those docs, hehe, the documentiation i've found about practical programming on the 80286 on the web
<2> there are no "memory rings". could you please stop talk about things you only have heard about. please read the manuals properly
<0> i didn't say memory rings
<1> actually, 286 PM was sort of neat.
<0> anyway the 386 segment level protection i was talking about is referenced here: http://pdos.csail.mit.edu/6.828/2005/readings/i386/s06_03.htm
<0> mwk: how so?
<1> well, it obviously isn't as great as 386's paging and flat space possibilty, but it actually works and provides decent protection mechanisms
<0> hm
<1> amusingly, 286 segmentation had execute protection, which wasn't available with 386's paging...
<2> it was flat. that was cool enough =)
<2> at least you could finally resize the segments
<1> which is now very sought-after, as a poor man's protection from viruses
<1> a shame they included it into paging as late as x86_64...
<1> but then, x86 was never very predicting...
<2> conclusion: all cpu **** ;)
<1> conclusion was 'all x86 cpu ****'... :)
<1> makes me want to go back to this old macintosh with pagingless protectionless 68000
<1> but with flat space!
<4> hi
<1> hi
<4> I'm trying to learn AT&T x86_64 ***embly, but i'm finding it difficult to find good resources, does anyone have a suggestion maybe?
<1> http://www.x86-64.org/documentation/***embly
<1> this ***umes knowledge of AT&T i386 ***embly
<3> http://tinyurl.com/5kfu6
<4> allright thanks
<4> i'll give them a look
<5> what is a good ***embler for linux, gas or nasm, something else?
<1> gas... just gas
<1> or nasm if you don't care about c<->asm integration
<5> the tutorial i'm reading is for nasm.. are they compatible?
<1> no.
<1> not at all
<5> heh
<4> yeah I figured I should learn AT&T syntax since a lot of tutorials on binary analysis etc. use gdb
<1> and AT&T syntax is for gas. yeah.
<5> is this "perfect linux ***embly book" gas compatible?
<4> lol "gas compatible" sounds funny
<5> :)
<3> its only about gas
<1> if ti describes gas, it's compatible
<5> then i guess it's compatible ;)
<1> if it describes nasm, it isn't.
<4> =)
<1> unless it explains both
<5> and it's a good book for a beginner?
<4> well the title sure implies it is
<5> lol
Return to
#asm
or
Go to some related
logs:
dhtml exampl
emacs 22 root access
debian mpg123 ALSA: underrun, at least 0ms.
#oe
ubuntu wpa ferrari
Engine ubuntulooks is unsupported
2.6.12-10 ntfs write
un_set in php
#bind
ubuntu amule server list
|
|