00:00:00 --- log: started forth/15.12.05 01:00:37 --- quit: xyh (Remote host closed the connection) 02:40:58 --- join: true-grue (~grue@176.14.216.104) joined #forth 02:42:25 --- quit: atommann (Ping timeout: 246 seconds) 03:20:41 --- quit: crc () 03:20:51 --- join: crc (sid2647@gateway/web/irccloud.com/x-aabtwxjelvatnehg) joined #forth 03:37:09 --- quit: ASau (Remote host closed the connection) 03:37:27 --- join: ASau (~user@netbsd/developers/asau) joined #forth 03:58:53 --- quit: bb010g (Quit: Connection closed for inactivity) 04:07:37 --- quit: proteusguy_satri (Ping timeout: 260 seconds) 04:32:15 --- join: atommann (~atommann@222.248.65.23) joined #forth 04:51:00 --- quit: asagk (Ping timeout: 260 seconds) 04:58:57 --- quit: proteusguy (Ping timeout: 260 seconds) 05:03:42 --- join: asagk (~asagk@i59F6B19E.versanet.de) joined #forth 05:07:22 --- join: aftershave (~textual@h-137-26.a336.priv.bahnhof.se) joined #forth 05:13:25 --- join: proteusguy (~proteusgu@ppp-110-168-229-106.revip5.asianet.co.th) joined #forth 05:13:25 --- mode: ChanServ set +v proteusguy 05:15:37 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 05:16:23 --- join: proteusguy_satri (~proteusgu@ppp-110-168-229-106.revip5.asianet.co.th) joined #forth 05:37:57 --- quit: atommann (Quit: Leaving) 05:38:05 --- quit: aftershave (Quit: Textual IRC Client: www.textualapp.com) 05:50:56 --- join: xyh (~cicada@183.15.140.143) joined #forth 06:17:48 --- quit: asagk (Ping timeout: 260 seconds) 06:30:41 --- join: asagk (~asagk@89.246.185.148) joined #forth 07:11:31 --- join: Kumool (~kumool@adsl-64-237-232-93.prtc.net) joined #forth 07:26:02 --- join: mnemnion (~mnemnion@c-68-40-49-135.hsd1.mi.comcast.net) joined #forth 07:50:28 --- quit: Keshl (Read error: Connection reset by peer) 07:51:08 --- join: Keshl (~Purple@24.115.181.94.res-cmts.gld.ptd.net) joined #forth 08:07:28 --- quit: asagk (Ping timeout: 260 seconds) 08:16:51 --- join: Bahman (~Bahman@188.245.245.221) joined #forth 08:20:32 --- join: asagk (~asagk@i59F6CD80.versanet.de) joined #forth 08:38:16 --- quit: asagk (Ping timeout: 260 seconds) 08:44:22 --- quit: mnemnion (Remote host closed the connection) 08:45:21 --- join: mnemnion (~mnemnion@c-68-40-49-135.hsd1.mi.comcast.net) joined #forth 08:47:25 --- join: true-grue_ (~grue@176.14.216.104) joined #forth 08:49:42 --- quit: mnemnion (Ping timeout: 245 seconds) 08:49:56 --- quit: true-grue (Ping timeout: 260 seconds) 08:51:07 --- join: mnemnion (~mnemnion@2601:400:8000:3da0:9d02:d79f:e81d:2e83) joined #forth 08:52:22 --- join: asagk (~asagk@i59F6C410.versanet.de) joined #forth 09:13:42 --- quit: Zarutian (Quit: Zarutian) 09:23:19 --- join: bedah (~bedah@dyndsl-031-150-091-138.ewe-ip-backbone.de) joined #forth 09:41:01 --- quit: Bahman (Quit: Ave atque vale) 10:12:05 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 10:23:33 --- join: bb010g (uid21050@gateway/web/irccloud.com/x-oqfhdcnphujfkazo) joined #forth 10:35:39 --- join: mat4 (~claude@ip5b4112a4.dynamic.kabel-deutschland.de) joined #forth 10:35:41 hello 10:42:31 --- nick: mat4 -> mat4-work 11:17:41 --- quit: mnemnion (Remote host closed the connection) 11:20:42 --- join: mnemnion (~mnemnion@c-68-40-49-135.hsd1.mi.comcast.net) joined #forth 11:26:17 --- quit: xyh (Quit: ChatZilla 0.9.92 [SeaMonkey 2.39/20151111142545]) 11:46:30 --- nick: mat4-work -> mat4 11:58:01 --- quit: Kumool (Ping timeout: 260 seconds) 11:58:59 --- join: Kumool (~kumool@adsl-64-237-232-93.prtc.net) joined #forth 12:26:00 h'lo mat4 12:26:21 hi Zarutian 12:28:55 been wondering what exactly the difference is between hardwired and rom microcoded core is 12:34:11 hardwired microcode generate instruction sequences where a microcode ROM contains them 12:35:29 however because process implementation very at wide scale ther terminology may differ also 12:35:36 ^there 12:37:15 sorry, I mean processing implementations differ at wirde scale, the terminology differs in the same range 12:37:38 * mat4 need to buy a new keyboard soon 12:41:44 the usual big difference is that rom ucode often does a bunch of internal instructions per external instruction 12:43:04 the fact that is uses a rom does not matter /an sich/, that's just an implementation detail 12:43:26 to my knowledge a hardwired microcode core i s mostly used in combination with an internal trace buffer to avoid microcode ROM access (times) 12:45:30 the microcode engine emit instruction sequences directly into the buffer from which execution is done either out-of-order or in-order 12:47:15 I am talking about the stuff that takes in instructions and outputs control signals to the cores datapaths 12:47:44 i read the question as "hardwired" vs. "rom microcoded", not "hardwired microcoded" vs. "rom microcoded" :-) 12:48:48 whether the implementation uses a rom or not to do its decoding is rather unimportant 12:49:21 well you can go with unencoded like Novix 4016 did it 12:50:14 i wouldn't call that "unencoded", but the external instructions are much like what the core does, yeah 12:50:49 "unencoded" instructions are 200 bits or so at least, heh (all control signals directly) 12:51:15 segher: depends on the complexity of the datapath 12:51:18 4016 is more like old0style risc 12:51:22 sure 12:51:37 but you need 50 or so at the minimum 12:52:50 why? I thought around 20 was the max one would need on dual stack architectures 12:53:15 I am not talking about cores with huge and complex register files 12:53:21 you need a signal for all your alu ops, one for each of your stack ops, etc. etc. 12:54:06 there exist processors which expose the datapath directly (in this logic realize a 'true'unencoded instruction format). That are zero-instruction designs 12:54:24 so if you have e.g. a 4-bit field for 16 different alu ops, you still need to decode that 12:55:01 mat4: yeah, but you can go as far as calling those state machines really :-) 12:55:13 yes 12:55:26 segher: hmm, what if we only have three 'ALU' ops? XOR, AND and <<1 12:55:28 you're talking about very deeply embedded cores, right? 12:55:56 segher: the simplest possible cores basically 12:56:01 zarutian: if your insn has a 2-bit field for those, you still need to decode it to 3 signals 12:56:30 segher: or just have 3 bit field for them 12:56:34 yes 12:56:46 but you almost never see *that* 12:56:50 wont make any sense to do 111 or 011 or any such variation 12:57:15 decoding isn't bad at all if you can do it very cheaply 12:57:30 in fact most microcode insns still need some decoding 12:57:39 a PAL for example would help 12:57:53 "flattening out" everything isn't too useful 12:58:24 mat4: oh those. I thought they were completely put out to pasture 12:59:32 except in fpgas... 12:59:56 segher: indeed but what I have found is that there is some assumption made in design of ISA that requires pulling in pipelining, out of order execution and such 13:00:31 of most ISAs that is 13:00:43 if you want high performance, you need pipeling alright 13:00:54 +in 13:01:37 even 6500 already had 2-cycle overlap 13:01:40 segher: what problem does pipelineing solve precisely? The length of the fetch->execute cycle? 13:02:09 it makes the cycle time shorter than the fetch->completion time 13:02:40 okay what is the cause of long fetch->completion times? 13:02:47 higher clock frequences lower cirquit timing requirements 13:03:21 it doesn't matter what the cause is 13:03:36 if insns do (say) steps A B C D 13:03:54 segher: it does matter, if you can eliminate it then you dont need to spend silicon die space on it 13:04:06 then the time it takes to do A+B+C+D is always more than the max time to do either A, B, C, or D 13:04:18 sure 13:04:23 segher: also you get much faster interrupt response. 13:04:36 if non-pipelined is fat enough for you, then you can save space 13:04:42 fast 13:05:15 another often made assumption is that there is only one (or few) cores doing the execution of code from main memory 13:05:28 I think it make no sense to discuss this topic without restricting the application demands 13:05:33 pipelining does not in general make interrupt reponse slower 13:06:07 mat4: yeah. you do not always *want* the fastest 13:06:15 most things are a tradeoff 13:06:16 segher: it doesnt makes it slower but it is just as fast as the uninterputed instruction stream 13:06:28 only few things are better than the alternative in all dimensions 13:06:51 but it isnt as fast as the uninterupted instruction stream I mean 13:07:06 not sure what you mean 13:07:41 for fast interrupt and subroutine-call latency, pipelining expense the implementation complexity for sure I think 13:08:14 segher: lets say the core is doing A, B, C and D instructions. All of them ALU or memory fetches. 13:08:47 simply because branches easily stall the pipeline 13:08:59 mat4: exactly 13:09:35 mat4: if you look at how 6500 (and 6800 actually) do it... 13:09:57 interrupts simply force a special "interrupt" instruction into the instruction stream 13:10:58 another simple way is just forwarding the call or don't issue branches at all 13:11:48 however all these strategies cost some additional logic which widens the cycle time (a bit) 13:13:01 if I undertand Zarution right, that is his point 13:13:06 ^understand 13:13:19 not every addition costs cycle time 13:14:08 mat4: funnily enough I saw on the net many years ago that someone had implemented an emulator for a simple core in x86 assembly that had only one branch instruction. And that instruction was basically something like JUMP start. It ran some branch heavy benchmarks faster than the x86 did. 13:14:48 i'm a fan of the old-time "skip" flag 13:15:04 segher: hmm well, it depends on the state implementation for example (we talking about implementation dependent details) 13:15:29 various insns can set the skip flag, which causes the next insn to be skipped (actually, nopped out usually) 13:15:50 widens the cycle time (a few transistor delays) eats up die space and such 13:17:08 segher: then you should read up on instruction mux bit fields, I think ARM did it in one iteration of their designs 13:17:09 if you're talking about a clocked design, you already have at least 20 or so gate delays per cycle 13:18:29 segher: basically an instruction got executed only if certain control register matched the mux field 13:18:52 hehh fun 13:19:09 is this an old arm core? 13:19:13 segher: part of the control register was actually the status register but also one part was settable as idx by some instructions. 13:19:41 rather old and I am not sure it made it into any ARM core design. 13:19:50 are you talking about the original thumb implementation, perhaps? 13:19:59 ah 13:20:01 nope 13:22:09 each instruction took up whole 32 bit words iirc 13:27:39 and the reason why I have been thinking about this is Secure Multi Party Computation based on boolean logic. One annoyance is that an AND gate delay is a whole network Round Trip Time. 13:29:58 (and the SMPC boolean implementation only gives you AND and XOR gates) 14:25:14 --- quit: true-grue_ (Read error: Connection reset by peer) 14:55:35 --- quit: Zarutian (Quit: Zarutian) 14:56:43 --- quit: mat4 (Quit: Leaving) 16:02:25 --- quit: bedah (Quit: Ex-Chat) 17:05:52 --- quit: impomatic (Ping timeout: 246 seconds) 17:42:27 --- quit: Keshl (Read error: Connection reset by peer) 18:37:06 --- join: karswell` (~user@253.54.199.146.dyn.plus.net) joined #forth 19:01:23 --- nick: karswell` -> karswell 19:30:40 --- quit: ASau (Ping timeout: 260 seconds) 19:31:52 --- join: Bahman (~Bahman@5.238.211.162) joined #forth 19:34:39 --- quit: Bahman (Client Quit) 19:35:11 --- join: Bahman (~Bahman@5.238.211.162) joined #forth 19:59:01 --- join: Bahman_ (~Bahman@5.238.190.176) joined #forth 20:01:47 --- quit: Bahman (Ping timeout: 245 seconds) 20:06:47 --- nick: Bahman_ -> Bahman 20:40:07 --- join: proteusguy_ (~proteusgu@ppp-110-168-229-103.revip5.asianet.co.th) joined #forth 20:40:30 --- quit: nighty^ (Quit: Disappears in a puff of smoke) 20:41:22 --- quit: proteusguy_satri (Ping timeout: 245 seconds) 20:41:28 --- quit: proteusguy (Ping timeout: 246 seconds) 20:55:14 --- join: proteusguy_satri (~proteusgu@ppp-110-168-229-103.revip5.asianet.co.th) joined #forth 21:01:38 --- join: Kumool_ (~kumool@adsl-64-237-235-160.prtc.net) joined #forth 21:03:09 --- quit: Kumool (Ping timeout: 246 seconds) 21:57:25 --- quit: Kumool_ (Read error: Connection reset by peer) 22:19:14 --- quit: mnemnion (Remote host closed the connection) 22:42:17 --- quit: DGASAU` (Read error: Connection reset by peer) 22:42:36 --- join: DGASAU` (~user@lmpc.drb.insel.de) joined #forth 23:00:03 --- quit: DGASAU` (Ping timeout: 246 seconds) 23:19:48 --- join: mnemnion (~mnemnion@2601:400:8000:3da0:75dd:b433:99eb:7b3) joined #forth 23:24:10 --- join: xyh (~cicada@183.15.140.143) joined #forth 23:24:56 --- quit: mnemnion (Ping timeout: 260 seconds) 23:40:55 --- quit: xyh (Quit: ChatZilla 0.9.92 [SeaMonkey 2.39/20151111142545]) 23:59:59 --- log: ended forth/15.12.05