00:00:00 --- log: started forth/17.06.14 00:18:40 --- quit: retopamp (Read error: Connection reset by peer) 01:45:13 --- join: John[Lisbeth] (~user@c-73-239-38-28.hsd1.wa.comcast.net) joined #forth 01:45:19 --- part: John[Lisbeth] left #forth 02:23:37 --- quit: fiddlerwoaroof (Ping timeout: 268 seconds) 02:24:58 --- join: fiddlerwoaroof (~fiddlerwo@unaffiliated/fiddlerwoaroof) joined #forth 03:04:17 --- quit: zy]x[yz (Ping timeout: 260 seconds) 03:20:09 --- quit: fiddlerwoaroof (Ping timeout: 260 seconds) 03:27:46 --- join: fiddlerwoaroof (~fiddlerwo@unaffiliated/fiddlerwoaroof) joined #forth 03:38:32 --- join: GeDaMo (~GeDaMo@62.56.75.248) joined #forth 03:49:22 --- quit: nighty- (Quit: Disappears in a puff of smoke) 03:51:19 --- quit: fiddlerwoaroof (Ping timeout: 260 seconds) 04:12:53 --- join: MickyW (~MickyW@p4FE8D1EB.dip0.t-ipconnect.de) joined #forth 04:14:50 --- join: zy]x[yz (~corey@unaffiliated/cmtptr) joined #forth 04:32:12 --- join: nighty- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 04:39:40 --- join: fiddlerwoaroof (~fiddlerwo@unaffiliated/fiddlerwoaroof) joined #forth 04:49:56 --- quit: fiddlerwoaroof (Ping timeout: 240 seconds) 04:52:21 --- quit: mtsd (Ping timeout: 260 seconds) 06:00:09 --- quit: proteusguy (Remote host closed the connection) 06:09:22 --- join: fiddlerwoaroof (~fiddlerwo@unaffiliated/fiddlerwoaroof) joined #forth 06:17:07 --- quit: fiddlerwoaroof (Ping timeout: 246 seconds) 06:36:22 I keep seeing mention of "table-driven assembler," but I'm having a difficult time finding anything written about it except for example codebases which are designed to target 50 different platforms, not commented, and are pretty involved to try to follow 06:36:26 any pointers? 06:37:52 I've come up with a couple of ideas about how I'd do it, but they don't seem to solve much. so I was hoping I could find some text about table-driven assembler design that would help me realize what it is I'm missing 06:38:20 --- join: proteusguy (~proteus-g@49.228.92.234) joined #forth 06:38:20 --- mode: ChanServ set +v proteusguy 06:49:57 --- join: mark4 (~mark4@99.30.241.51) joined #forth 07:04:37 --- join: Chef_Gromboli (~Chef_Grom@static-72-88-80-103.bflony.fios.verizon.net) joined #forth 07:11:45 --- join: true-grue (~true-grue@176.14.219.178) joined #forth 07:24:45 --- join: fiddlerwoaroof (~fiddlerwo@unaffiliated/fiddlerwoaroof) joined #forth 07:32:08 --- quit: fiddlerwoaroof (Ping timeout: 255 seconds) 07:45:49 --- join: fiddlerwoaroof (~fiddlerwo@unaffiliated/fiddlerwoaroof) joined #forth 08:04:51 Perhaps You can also ask in ##asm #compilers ior ##binutils. 08:05:27 zy]x[yz: Writting Your own assembler for AMD64? 08:05:31 ##asm is, in my experience, not very helpful. I haven't tried the other two though, thanks 08:05:34 yes 08:05:50 Awesome :) . 08:05:51 or at least some pathetic attempt at it 08:12:18 --- quit: fiddlerwoaroof (Ping timeout: 240 seconds) 08:35:45 Have you heard about qhasm? 08:35:56 no 08:36:55 https://cr.yp.to/qhasm.html 08:40:32 All my assemblers use algebraic syntax. I think every modern assembler should get rid from archaic mnemonics. 08:40:57 oh cool this is a djb product 08:44:03 anyway, as neat as this looks, it's really not at all what I was asking for 08:46:53 http://dl.acm.org/citation.cfm?id=907986 08:48:26 --- part: dys left #forth 08:49:01 --- join: dys (~dys@ip-109-44-3-111.web.vodafone.de) joined #forth 08:49:11 http://hackaday.com/2015/08/06/hacking-a-universal-assembler/ 08:50:15 I've seen that last one 08:50:38 it talks a lot about parsing and semantics but not about the actual assembler 08:50:56 specifically table-driven assembler design 08:52:31 Table-driven assemblers are good for some simple architectures. I see no reason to use this approach for something like CISC/VLIW/etc. 08:54:58 oh. I had the opposite impression: that table-driven assemblers simplified CISC ISAs 08:55:54 The main reason for the table-driven assembler is not to make something for the people who can't understand parsing, it's for retargetability. And this goal was not reached. 08:56:50 zy]x[yz: is there a reason you don't want to do a typical forthy assembler with operand words that build up operands on the stack (or elsewhere) and instruction mnemonic words that consume those and encode an instruction? 08:56:52 You need to have something more powerful than tables to implement retargetable tool. 08:57:19 See LISA and other ADLs. 08:58:41 koisoke, I'd be fine with "typical forthy assembler" but I have to somehow handle mnemonics that are encoded differently depending on their operand types. like I said, I was given the impression that table-driven design is supposed to simplify this, but if that was a misconception then I'm not married to it 08:59:12 I started down a more "brute force" approach at one point and the complexity just gets unmanageable 08:59:50 in short: I don't know what the hell I'm doing 09:00:46 looks like gforth's assembler mostly has a lot of IF .. ELSE .. in the definitions for instructions like that 09:00:51 the only good article I've seen is brad rodrigueze's, but his approach is way to simplistic for my needs, and his answer to "what do you do with more complex ISAs?" is "I avoid them" 09:01:41 (and this looks to only support a subset) 09:02:07 which is fine 09:02:13 I'll take a look at it. thanks 09:15:21 So typically, there is one encoding for adding registers, and another encoding for adding an immediate value, right? 09:16:01 typically, but x86 is not typical 09:16:14 I made my x86 assembler handle this with a single "add," mnemonic. But in hindsight, the forthy thing would have been to provide separate "add," and "addi," mnemonics. 09:16:40 in that it has a huge proliferation of arithmetic encodings 09:17:12 using separate mnemonics for each encoding was the "brute-force" approach I mentioned that I had started earlier and abandoned because it was ridiculous 09:18:21 you have to have add-reg-reg, add-reg-[reg] and all of the variants that come with it ([reg+reg*scale], etc), add-reg-imm, and then all of those can be sized differently so you really need add-reg32-imm8, add-reg32-imm32, add-reg16-imm8, etc. 09:19:16 and then there are special cases for rsp and rbp 09:21:28 so what I've started to do is that each operand builds a sort of signature, and then when the mnemonic is invoked that signature becomes the index into a table which maps to the encoding word. I guess I'm on a path to something that might work, but again, I don't know what the hell I'm doing and just wanted to see some text written by somebody whose done it before 09:21:33 I belive that Brad Rodriguez could implement it all very elegantly with his tools like PatternForth and BNF Parser :) 09:21:33 who's 09:23:53 Sounds like you're on the right track. 09:27:42 yeah. sounds like the right track but a straightforward table lookup with no logic in the instruction words can't (so far as i can see) cope with e.g. encodings for different immediate sizes 09:29:23 right 09:30:23 but roughly that, with a jump table for xt to do the instruction encoding instead of a table of literal opcode values is probably how i would do it 09:31:01 oh no, it's a jump table 09:31:46 in other words, it boils down to "key @ table[] @ execute" 09:34:17 --- quit: mark4 (Ping timeout: 246 seconds) 09:35:25 sounds reasonable then 09:49:36 --- join: mark4 (~mark4@99.30.241.51) joined #forth 09:54:42 I avoided IFs. Most logic is done through deferred words. 09:56:53 --- quit: MickyW (Quit: Leaving. Have a nice day.) 10:43:05 --- join: opamp (~textual@97-104-93-154.res.bhn.net) joined #forth 10:52:28 --- quit: mark4 (Remote host closed the connection) 10:52:56 --- join: mark4 (~mark4@99.30.241.51) joined #forth 11:23:18 --- quit: opamp (Quit: My MacBook has gone to sleep. ZZZzzz…) 11:23:51 --- join: gravicappa (~gravicapp@ppp83-237-165-135.pppoe.mtu-net.ru) joined #forth 11:33:52 --- join: opamp (~textual@97-104-93-154.res.bhn.net) joined #forth 11:37:24 --- quit: opamp (Client Quit) 11:39:08 --- join: MickyW (~MickyW@p4FE8DDC3.dip0.t-ipconnect.de) joined #forth 12:17:31 --- quit: mark4 (Ping timeout: 240 seconds) 12:26:39 --- join: mark4 (~mark4@99.30.241.51) joined #forth 12:27:53 --- join: opamp (~textual@97-104-93-154.res.bhn.net) joined #forth 12:28:33 --- quit: opamp (Client Quit) 12:53:14 --- join: karswell` (~user@213.2.9.51.dyn.plus.net) joined #forth 13:00:46 --- quit: mark4 (Ping timeout: 255 seconds) 13:02:01 --- quit: true-grue (Read error: Connection reset by peer) 13:07:30 --- join: true-grue (~true-grue@176.14.219.178) joined #forth 13:19:32 --- join: diaperglu (42d516c1@gateway/web/freenode/ip.66.213.22.193) joined #forth 13:21:59 --- quit: dys (Remote host closed the connection) 13:26:42 --- quit: GeDaMo (Remote host closed the connection) 13:32:42 --- quit: diaperglu (Quit: Page closed) 13:36:27 --- join: dys (~dys@ip-109-44-3-111.web.vodafone.de) joined #forth 14:30:03 --- quit: gravicappa (Ping timeout: 268 seconds) 15:19:48 --- quit: MickyW (Quit: Leaving. Have a nice day.) 15:33:00 --- quit: true-grue (Read error: Connection reset by peer) 15:37:37 --- join: mark4 (~mark4@99.30.241.51) joined #forth 15:59:24 --- join: wa5qjh (~Thunderbi@121.54.90.146) joined #forth 16:16:38 isnt the case that x86 is hopelessly complexified? 16:17:23 there are some addressing modes, prefixes and such that make little sense and see little use afaict 16:22:44 I don't know if I'd say "hopelessly" seeing as working assemblers for it do exist, but yeah it is quite the mess 16:27:02 saw a spec somewhere (I do not remember where nor its name) of a zero operand instruction dual stackmachine that had extra instructions that worked like register fetches&stores and addressing modes. 16:27:57 the speed of it would have been the same as in order x86 if implemented in hardware the author claimed 16:32:02 --- quit: wa5qjh (Read error: Connection reset by peer) 16:33:49 --- quit: nighty- (Quit: Disappears in a puff of smoke) 17:02:08 so in other other words the operands are encoded in the opcodes 17:05:37 I wonder if x86 has a subset of instructions such that you could treat it that way and be perfectly happy 17:51:28 --- join: nighty- (~nighty@kyotolabs.asahinet.com) joined #forth 18:09:12 --- join: wa5qjh (~Thunderbi@121.54.90.146) joined #forth 18:16:26 --- join: proteus-guy (~proteus-g@49.228.120.190) joined #forth 18:18:48 --- quit: proteusguy (Ping timeout: 240 seconds) 18:35:32 --- quit: wa5qjh (Quit: wa5qjh) 20:15:58 --- join: fiddlerwoaroof (~fiddlerwo@unaffiliated/fiddlerwoaroof) joined #forth 21:47:41 I certainly only support a subset of x86 instructions and addressing modes in my assembler. Basically what I use in my kernel. 21:51:53 --- join: smokeink (~smoke@175.20.93.177) joined #forth 21:51:54 --- quit: smokeink (Client Quit) 23:29:14 theres a document that shows the x86 opcode encodings in octal which makes them make sense. hex encoding of opcodes just obfuscates things 23:59:29 --- quit: Chef_Gromboli (Quit: Leaving) 23:59:59 --- log: ended forth/17.06.14