#pentagram@irc.freenode.net logs for 30 Sep 2002 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage

[01:04:41] <-- wjp has left IRC ("Zzzz....")
[06:44:34] --- Darke|afk is now known as Darke
[10:32:25] <-- Darke has left IRC (gibson.freenode.net irc.freenode.net)
[10:32:56] --> Darke has joined #pentagram
[10:54:14] * Darke has a dilemma with disasm.
[10:54:54] <Darke> Currently, when it handles reading an opcode, it automatically prints it out.
[10:55:24] <Darke> Now this can be gotten around with the #define printf macro I've got in there, but it's quite a hack.
[10:56:56] <Darke> It's also not going to work well, when we split the opcode input between u8/crusader and the new pentagram opcodes, since the'll be a lot of duplication of print statments, along with the duplication of reading.
[10:57:53] <Darke> It's also not elegant enough, should we want to output to something other then stdout, say a ConsoleGump? Or a UsecodeTracerGump.
[10:59:02] <Darke> AFAICT, there's two ways of handling this.
[10:59:23] <Darke> Either write the data into a generic container (this is what FoldOp is used for in fold).
[11:01:32] <Darke> Or get it to return a 'new'ed specific Node class. For example again using fold, returning a BinMathNode containing an abstraction of the 'add' opcode. Or a PushVarNode containing type/size and actual data.
[11:02:46] <Darke> The first (FoldOp) should be faster and reduces memory fragmentation (also doesn't have all the messy pointers floating around which can be forgotten to be deleted), as well as having a smaller memory footprint.
[11:04:32] <Darke> The second is going to be cleaner to implement, since the 'convert' function itself reads the opcodes into a more abstract representation, which you can then output to anything, like the pentagram script, original opcodes, a different opcode format, or can even be recompiled.
[11:42:33] <Darke> On a completely unrelated note, the 'urandom(int)' intrinsic really should be an opcode. *grin* I'd also suggest that things like Item::getX, Item::getY and Item::getZ, should be opcodes too due to the frequency they're called at, and the almost absence of data they're provided with. Of course, following that logic, Item::bark() should also be an opcode, due to the fact it's called 4533 times in the u8e2.13 usecode, but that seems more th
[11:42:34] <Darke> bit silly IMO.
[11:46:58] <Darke> It's a bit surprising how rarely some opcodes are called, whereas some others are called an amazing amount of times. Item::bark for an example appears to be called about as often as all the other intrinsics in the game. *grin*
[11:51:02] * Darke yawns and should go to sleep, he probably sounds about as incoherent as he feels. *grin*
[11:51:07] --- Darke is now known as Darke|afk
[12:35:57] --> Colourless has joined #Pentagram
[12:35:57] --- ChanServ gives channel operator status to Colourless
[12:41:52] <Colourless> hey darke, why not just change everything to 16 bit opcodes :-)
[12:42:04] <Colourless> no more intrinsics :-)
[12:43:09] <Colourless> seriously, i don't think it matters very much
[12:43:55] <Colourless> i would tend to think though that opcodes should really be like those of a real cpu
[12:44:15] <Colourless> anything that is 'complex' and does more than just a simple operation should be an intrinsic
[12:45:25] <Colourless> by that arguement only arithmetic operations, stack operations, pointer operations and function calls/process creating should be opcodes
[12:45:52] <Colourless> ideally process creating shouldn't be an opcode either, i really just don't know how we'd probably get it to work as an intrinsic
[12:47:01] <Colourless> of course a number of the other opcodes should be what I would class as functions. these are mostly just the few misc process opcode (exclude and set info among others)
[12:47:48] <Colourless> all it's got to do is the easiest way of actually implementing the interpreter
[12:48:21] <Colourless> usually the opcodes are in a huge switch statement, while the functions exported by the engine are in a table
[12:52:17] <Colourless> now, just for a moment i'm going to assume that everything just uses a single 16 bit opcode with no opcode to call an intrinsics. What could just be done is the first 256 opcodes could be strictly reserved for opcodes so we could do if (opcode < 256) { opcode_switch } else { lookup_function_and_execute; }
[12:53:17] <Colourless> i personally would be slightly against such a move as it would most likely just increase the size of the code
[12:53:35] <Colourless> i would really just leave things as is
[12:54:06] <Colourless> now about output:
[12:54:33] <Colourless> all output should be redirected to our own output functions/streams
[12:56:23] <Colourless> so instead of calling printf() we would use something like pent_printf(); and pentout and penterr for the streams, then we can easily change settings for output
[12:58:02] <Colourless> of course that is only really relevant for the general output everywhere in the engine
[12:58:25] <Colourless> as your code seems to be related to conversion, i really don't have an opinion either way
[13:01:17] <Colourless> chances are anything you could do with that would probably be useful for the compiler you were working on so i would say use the method that would create code that would be most useful for both
[13:03:30] <Colourless> if you wanted output while executing... then i can imagine that doing things similar to disasm would be best. might be ugly, but it would be fastest
[13:03:47] <Colourless> now since you need to read all the data anyway, you shouldn't have to be doing duplications
[14:33:30] <-- Darke|afk has left IRC (gibson.freenode.net irc.freenode.net)
[14:35:19] --> Darke|afk has joined #pentagram
[16:06:19] <-- Colourless has left IRC ("bbl")
[19:27:25] --> Colourless has joined #Pentagram
[20:28:40] * Darke|afk bows and shall try to quickly respond before rushing off to work. *grin*
[20:28:45] <Darke|afk> (16bit opcodes) No! Evil!
[20:28:52] <Colourless> :-)
[20:29:11] <Colourless> as i stated in the end, i do'nt like the idea either ;-)
[20:31:03] <Darke|afk> (random) For some reason, this always 'feels' like an opcode to me. *grin* And being able to do something like '?25' to generate a random number between 0 and 24 would be neat I think. *grin, duck*
[20:31:50] <Colourless> um, well, you do know that it doesn't need to be an opcode to do that
[20:32:16] <Colourless> all you'd need to do is make the ? operator create a call opcode that calls the correct function
[20:34:04] * Darke|afk nods. But it wouldn't be consistant with all the other operators. All access to the intrinsics is by explicit execution afaict, rather then an implicit token->function call translation. *grin* I think that's why having it as an opcode makes more sense to me. *shrug*
[20:34:25] <Colourless> operator overloading ! ;-)
[20:34:53] * Darke|afk thwaps! Bad dragon! Don't say those evil words! *grin*
[20:35:02] <Colourless> then again, you could just call the random funtion ? :-)
[20:37:36] <Darke|afk> (disasm) With the FoldOp/Node thing. I'd have to have both, or at least have my return-a-Node one be a wrapper around the FoldOp one for each ConvertFoo class.
[20:39:09] * Darke|afk imagines the 'core' of disasm to be something like `delete printNode(convert->nextOpcode());` in that situation, but suspects precedence ordering will mess with something as *cough* elegant as that. *grin*
[20:43:31] <Colourless> i think i really should be going
[20:43:46] <Darke|afk> Bye! Have fun!
[20:43:55] <Colourless> just leave your comments here and we'll continue this conversation with 12 h lag times :-)
[20:44:07] <-- Colourless has left IRC ("things to do... such as sleep")
[20:49:09] --> Dominus has joined #pentagram
[20:49:21] <Dominus> ?logs
[20:49:21] <exultbot> Logs are available at http://www.math.leidenuniv.nl/~wpalenst/exultlog.php3
[20:49:34] <Dominus> that is not the correct address my dear bot
[20:52:44] * Darke|afk pawwaves. Hi Dominus!
[20:53:05] <Darke|afk> Blame wjp, even he's forgotten to rejoin this channel. *grin*
[20:53:27] <Dominus> you are not really here, you are afk, so it must be an darke impersonator...
[20:53:56] * Darke|afk is about to wander off to work. So something like that. *grin*
[20:54:05] <Dominus> so it seems slowly but steady something is happening here...
[20:55:39] <Darke|afk> Ever so slowly. *grin*
[20:57:24] <Dominus> good enough for me, though I'm always curios when something happens in the old repository...
[20:57:35] * Darke|afk is at the point where the disassembler/decompiler/compiler are borging into interfaces to a general 'usecode' library. *grin*
[20:58:01] <Dominus> hm, sounds good
[21:00:40] * Darke|afk pawwaves and disappears off to work. Bye!
[21:01:10] <Dominus> bye
[22:31:56] <-- Dominus has left IRC ("enough for now")
[23:49:42] <-- Darke|afk has left IRC (gibson.freenode.net irc.freenode.net)