| |
| |
| |
|
Page: 1 2
<bockman> i'm trying to cmp on (%ebp) and an .equ value like this: cmpl ST_ARGC(%ebp), $NUMBER_ARGUMENTS
<bockman> but as is throwing errors, what did i do wrong?
<imaginator> bockman: try cmpl $NUMBER_ARGUMENTS,ST_ARGC(%ebp) from what I understand the x86 only supports the immediate as a certain operand.
<bockman> yes i figured that out, i believe it's the at&t syntax, thanks though
<imaginator> the Intel manual I just referenced lists the imm32 as the second operand in all encodings, so it would always be the first in gas/at&t.
<aFlag> i can't find the modules on linux where the task switch takes place, does anyone knows where it is?
<aFlag> i'm trying to find it on linux 2.6.8
<winicius> I'm having a little problem with this given code: http://www.fileh.com/shrisis/factorial.txt ; my question is at the bottom of the page with the section of the code that I'm not understanding much.
<CaffeiniaNervosa> Does anyone in here have an opinion about "Art of ***embly Lanuage Programming" or "Write Great Code" by Randall Hyde?
<imaginator> winicius: I'm looking
<winicius> thanks = )
<winicius> By the way it compiles flawlessly and with the correct results.
<CaffeiniaNervosa> Hello imaginator and winicius
<winicius> Hello CaffeiniaNervosa
<CaffeiniaNervosa> Do you guys have any advice on a good intermediate book on ***embly?
<winicius> I do
<CaffeiniaNervosa> Care to share it?
<winicius> ok ill send it
<imaginator> Hi CaffeiniaNervosa
<CaffeiniaNervosa> Hello.
<winicius> imaginator did you see anything perculiar?
<CaffeiniaNervosa> I'm trying to find something that goes a little more in depth than Jeff Duntemann's "***embly Step by Step", and something a little more recent. I just grabbed Randall Hyde's "Art of ***embly" and "Write Great Code". I know they're targeted at HLA... I wondering just how useful they may be.
<CaffeiniaNervosa> I want to eventually start my own hobby OS.
<CaffeiniaNervosa> But, right now, I know enough to not be lost when I'm reading source code.
<winicius> Nervosa yo would want to try to learn a "high-level language"
<CaffeiniaNervosa> Well, I don't know. MenuetOS looks to be pretty solid, and it's entirely 64-bt ***embly.
<CaffeiniaNervosa> I like the idea of getting right down to the bare metal and working with the chip, ya know?
<CaffeiniaNervosa> I don't want to just use RPC, I want to understand how threads and processes are implemented at their core level.
<winicius> I see, but its a good idea to have a foundation in other areas also.
<winicius> Like a "handy man"
<illume> wow where has MenuetOS been all my life?
<CaffeiniaNervosa> Yeah, I have a pretty good grasp on C, C++, and a couple of other languages, and how they implement some of their features in the theoretical sense.
<CaffeiniaNervosa> lol illume
<CaffeiniaNervosa> It has a pretty simple API, too.
<CaffeiniaNervosa> It's understanding what's really going on behind the API I'm just not able to wrap my brain around yet.
<illume> hrmm
<illume> seems to be able to run a couple of fairly complex apps too
<CaffeiniaNervosa> Yep. And it's networkable, too.
<CaffeiniaNervosa> The original 32 bit version got branched off and has even more support from what I've gathered.
<CaffeiniaNervosa> Can someone tell me--because the books haven't arrived in the mail yet--is HLA bascially just macros, or is it some weird amalgom of ***embly and high-level constructs?
<bockman> yes i'd say it's weird. but that's my opinion. they're fine for most people though.
<CaffeiniaNervosa> macros are weird or HLA is weird?
<bockman> hla. when i did it i didn't like it
<CaffeiniaNervosa> I'm reading the online version of the book right now (for Linux).
<CaffeiniaNervosa> It seems you can use pure ***embly, HLA, or a mixture of the two, although the auther makes note that the primary reason for the book anymore is not so much to teach ***embly, but machine organization.
<CaffeiniaNervosa> So... I should still get something out of it. And, I can always look at the standard library to see how he does it.
<CaffeiniaNervosa> Woohoo, I guess.
<Jeaton> what do you guys think of gas
<Jeaton> or a ported version such as mingw's as
<CaffeiniaNervosa> gas ***embles all of the linux sources on my box just fine
<CaffeiniaNervosa> Granted, I don't "see" this, for it is a transparent process to me.
<CaffeiniaNervosa> The big thing you'll have to deal with is the AT&T syntax.
<CaffeiniaNervosa> I'd go with NASM.
<CaffeiniaNervosa> or FASM
<Jeaton> other than the terrible syntax, are there any other downsides?
<imaginator> sorry, I got busy
<CaffeiniaNervosa> It's online documentation at www.gnu.org is even worse than the syntax.
<imaginator> really? I think the documentation is nice and concise
<Jeaton> personally, I would rather use nasm, just I won't be able to inline asm into my c programs
<Jeaton> if i ever needed it, anyway
<CaffeiniaNervosa> You should be able to...
<CaffeiniaNervosa> I know a couple of my Linux programs use it as an optional dependency for inline optimizations.
<Jeaton> used nasm?
<imaginator> you can enable Intel syntax in recent gcc/binutils
<CaffeiniaNervosa> Yep.
<CaffeiniaNervosa> Hang on... lemme see if I can find one as a for example...
<Jeaton> ok
<imaginator> it really isn't much different from what I've seen. AT&T is more concise
<CaffeiniaNervosa> Okay, DirectFB and SDL both use it.
<CaffeiniaNervosa> It either produces slightly more effecient machine code, or the authors of DirectFB and SDL prefer it's syntax.
<CaffeiniaNervosa> It doesn't make sense to do that unless you're going to use Intel's compiler.
<CaffeiniaNervosa> Which is a ***** to setup on Linux.
<CaffeiniaNervosa> And it created some weird side effects when I recompiled glibc from what I remember.
<imaginator> I see that winicus /quit. here's my (AT&T syntax) solution http://rafb.net/paste/results/D7DW0t18.html
<CaffeiniaNervosa> I'm more interested in learning ***embly to make my own--probably irrelevant--OS than to develop for the Linux platform.
<CaffeiniaNervosa> I just happen to like Linux a lot better than Windows until Hurd comes to some level of stability.
<imaginator> I like NetBSD and run Linux software with the SuSE libraries
<imaginator> The HURD on L4 interests me though. I'm very curious about L4/Pistachio
<CaffeiniaNervosa> I can't imagine using ***embly in Linux aside from tightening a few critical loops. Linux really forces you to use C or some obfrusticated ***embly that some Russians figured out.
<CaffeiniaNervosa> Have you tried OpenBSD?
<CaffeiniaNervosa> I wonder if they're just going to move from Pistachio to Fiasco... lol
<imaginator> yes. I wrote several articles for O'Reilly about OpenBSD.
<CaffeiniaNervosa> Now THERE'S some distressful documentation: try cross compiling Hurd from source (without that Debian stuff).
<imaginator> I use asm in my code to speed up critical sections, and it's a lot of fun too, because it's challenging.
<CaffeiniaNervosa> Oh, really?
<CaffeiniaNervosa> I really wanted to like OpenBSD.
<imaginator> what issues did you have, the user community, deraadt?
<CaffeiniaNervosa> No so much the community itself...
<CaffeiniaNervosa> Not^
<CaffeiniaNervosa> The whole paradigm behind it.
<CaffeiniaNervosa> Sure, it's secure.
<CaffeiniaNervosa> But it's "not supposed" to be customized.
<CaffeiniaNervosa> And it came with what I would call baggage.
<CaffeiniaNervosa> Why force the user to have FVWM?
<imaginator> they just don't support anything but the default GENERIC kernel
<imaginator> FVWM is slightly easier than TWM, and it's small and ICCCM compliant.
<CaffeiniaNervosa> And what's his name... the head honcho ...just seemed a bit childish about his view of Linux.
<imaginator> he's chilldish about other things too I think.
<CaffeiniaNervosa> I prefer Enlightenment personally.
<CaffeiniaNervosa> Yeah... you got that impression, too?
<imaginator> yes
<CaffeiniaNervosa> That doesn't leave me with a sense of surety with the whole system.
<imaginator> it does have a lot more memory protections than other systems. but it all comes at a performance cost.
<CaffeiniaNervosa> I don't want an OS with an ulterior polical agenda in the code.
<imaginator> that's why DARPA dropped OpenBSD support through CHATS
<CaffeiniaNervosa> It IS secure... those Secure Levels were neat. They're in the Linux Kernel now too, though. *shrugs*
<imaginator> DARPA still uses OpenBSD though. in fact other parts of the government (even here in Utah) use it.
<CaffeiniaNervosa> I just made another switch from Gentoo to SourceMage recently.
<CaffeiniaNervosa> It's not BAD by any stretch of the imagination... just not what it was touted to be IMHO.
<CaffeiniaNervosa> Have you taken a look at MenuetOS yet, Imaginator?
<imaginator> I did years ago. I didn't understand enough asm at the time to really learn from it though
<imaginator> I recall it didn't support my graphics card too
<CaffeiniaNervosa> That's where I'm sitting at the moment.
<CaffeiniaNervosa> I'm pretty sure it supports VESA now, which almost any modern graphics adapter does.
<CaffeiniaNervosa> It's got my old "I want to learn ***embly" fire burning again. :) Moreso than V2OS.
<CaffeiniaNervosa> Maybe in a few years I'll have a preliminary NervOSa for everyone here to fiddle with. haha
<imaginator> someday I want to take the time to read the Intel Systems Programming Guide properly, so that I could work on things like that.
<imaginator> what's your goal for NervOSa ?
<CaffeiniaNervosa> I was looking at AMD's white papers the other day, shortly after seeing MeOS. There's a wealth of information in there, too, but it's obviously targetted at experienced systems designers.
<CaffeiniaNervosa> Oh, well, NervOSa was really just a play on my nick, Imaginator. But...
<CaffeiniaNervosa> My first goal would be to learn OS design at the nuts & bolts level.
<CaffeiniaNervosa> Maybe introduce a couple of design ideas I've read about but don't see: orthogonal storage...
<CaffeiniaNervosa> maybe take the exokernel paradigm and run with it.
<CaffeiniaNervosa> Unununium--no ****, that's how it's spelled--now written in Python, has a lot of neat ideas about how a system should work.
<imaginator> yah, I've read about that OS.
<imaginator> have you tried Unununium?
<CaffeiniaNervosa> Make the harddrive, or perhaps a partition, nothing more than a swap file, and treat memory as a sort of CPU cache.
<CaffeiniaNervosa> No, I haven't... have you?
<imaginator> not yet
<CaffeiniaNervosa> I can't see it being to fast, having been authored almost entirely in Python, but I like a lot of the ideas presented in it.
<CaffeiniaNervosa> There was another one that basically wrapped memory and physical storage in a flat address space. It was interesting, although the benefit from doing that was a little lost on me.
<imaginator> I'm getting the bootable ISO of Unununium to try it out in qemu
<CaffeiniaNervosa> I just might do that myself one of these days.
<imaginator> I'll try it in qemu after
<CaffeiniaNervosa> It kinda makes sense if you think about it. ``You open your wordprocessor. It prompts you for a Title (not a file name). You type some text. You close it. When you open it back up, it provides you the option of choosing an existing Title, or creating a new one. You can commit a copy manually under an alternative title, perhaps for versioning, if you want, but it's not necessary.``
<CaffeiniaNervosa> Hell, it would be nice just to be able to change the name of an open file sometimes.
<aPinecone1> what does the x86 "retn" instruction do? as in, "ret 4"?
<aPinecone1> retn 4, that is
<aPinecone1> anyone?
<poogle> retn is a near return
<poogle> ret is a near or far return
<aPinecone1> thanks, but I actually found the entry in the nasm manual
<aPinecone1> "RET, and its exact synonym RETN, pop IP or EIP from the stack and transfer control to the new address. Optionally, if a numeric second operand is provided, they increment the stack pointer by a further imm16 bytes after popping the return address."
<poogle> yep
<aPinecone1> Although is there some overwhelming reason to do this increment? can't it be done in the caller once the calee returns?
<poogle> dont have the answer to that one
<joshux> hi
<imaginator> poogle: from what I recall it can be used to implement a different calling convention where the callee cleans up its parameters that were pushed. I think windows supports that calling convention for some functions.
<imaginator> anyone know the name for that calling convention?
Return to asm
or
Go to some related
logs:
politics
planc
"warlocks are mushrooms""
|
|