00:00:00 --- log: started forth/05.10.08 00:22:42 --- quit: madgarden (Read error: 104 (Connection reset by peer)) 02:54:08 Hmm... 02:54:29 Is there any assembler with Forth as its macro programming language? 02:54:53 (I'd be happy with some other flexible one, but Forth seems like a natural choice) 03:34:00 which isn't enough flexible for your needs? 03:38:06 FASM... the macros are generally good, but I'd like to do some string manipulation assembly-time. 03:55:08 many forths are an assembler with forth as their macro programming language 04:01:42 lol... 04:01:49 yeah thats true.. 04:17:23 --- join: saon_ (n=saon@c-24-129-89-116.hsd1.fl.comcast.net) joined #forth 04:36:40 aum: Yes, but high-quality assemblers are sort of rare... 04:46:49 --- quit: saon ("Lost terminal") 04:48:29 --- join: saon (i=1000@c-24-129-89-116.hsd1.fl.comcast.net) joined #forth 04:52:56 --- join: amca (n=plump@as-bri-4-1-96.ozonline.com.au) joined #forth 05:04:46 I like the general minimalist of retroforth, is there any decent 386 assembler written for it? 05:04:51 minimalism* 05:06:17 I think there is one, the lib/assembler probably? 05:06:48 or if you would be really cool you could do it in the hex writing way... 05:10:07 Yeah, I don't really Ah, there it goes. 05:10:23 Heh, oops. 05:10:52 I found the assembler. And yes, I won't need that many instructions, so just writing the opcodes would work. 05:11:30 oh.. I'm such a retro guru here .. *lol* 05:30:00 good morning 05:31:57 Morning. 05:32:10 Does the assembler do forward references, crc? 05:32:45 I don't believe so 05:33:34 Hm, that's OK. 05:33:54 * Robert could probably abuse FASM macros. 05:42:04 --- quit: aum () 05:43:20 what are you trying to do with fasm's macros? 05:46:08 I want to create some object structures (for example, of symbol objects, containing a unicode string + its hash) - preferably assembly-time. 05:48:30 that should be doable, though the macros you'd have to write would be ugly (from what I've seen others do).... 05:49:23 Yes. What worries me most is that I'd have to use the code area to store data. 05:49:42 But since I'll have to store the strings as well, I don't think this will be a huge problem in this case. 05:59:32 --- part: amca left #forth 06:10:01 --- join: PoppaVic (n=pete@0-1pool47-79.nas30.chicago4.il.us.da.qwest.net) joined #forth 06:10:24 Howdy 06:10:31 Hi. 06:13:48 --- join: Topaz (n=top@wlan-160.ecs.soton.ac.uk) joined #forth 06:47:20 --- quit: saon_ ("Lost terminal") 07:19:50 --- quit: Robert ("Kill, kill, kill your screen, gently with an axe...") 07:21:32 --- join: Robert (n=robert@unaffiliated/robert) joined #forth 08:11:46 Robert: just threw you and tathi an email. Forgot attachment, damnit.. lemme' try again... 08:12:37 OK, sure. 08:12:40 OK, that's better 08:13:19 It's sorta' an RFC - I'm tinkering-up a pseudo-asm opcode-set. I just KNOW it's missing dozens of thingies. 08:14:06 Yeah..will have a look at it in a while. 08:14:11 Cool. 08:14:45 All you need to recall is XXX/xxx and YYY/yyy are just some register# 08:16:15 I've about concluded we are really further ahead "playing-assembler" for the pcode/compiled-code. Instead of just dickin' around with "compiling" high-level Forthish and STILL having to puzzle-out asm-ports, etc. 08:17:15 If we can play-assembler, we can write the basics in one place - and even translate it into real asm for any platform. 08:18:25 heh.. and, of course, it forms the base of a "compile-only" vocabulary. 08:25:26 I still think you should stick with a stack-based model, but whatever. 08:25:54 --- join: madgarden (n=madgarde@Toronto-HSE-ppp3708444.sympatico.ca) joined #forth 08:26:25 well, ok. Stack-based is a lovely idea. Not sure how that changes the basics exactly. Remember, we just want an "emulator layer" that can be ported fairly easily. 08:26:50 hmm...I don't understand all of this... 08:26:55 what are the 0x1A opcodes? 08:27:13 If you can see how all that stuff is torqued into a "stack-based", by all means reply email with the answer. 08:27:22 what line, tathi 08:27:37 starting at 58 08:28:01 byte-prefixes/window to a new set of codes 08:28:37 I don't follow 08:28:48 line 69+ codes would follow those line 58 bytes 08:29:10 #b is a byte, #h is a short, # alone is a CELL 08:29:12 oh. 08:30:06 sorta' Z80-like (by my rusty memory) 08:31:08 So...you're planning on using this opcode set instead of a forth-like one? 08:31:14 s/planning/thinking about/ 08:32:00 I'm sort of thinking my forthish-compiler should "compile" these opcodes as "asm" and we then have forth "secondaries" support atop it. 08:33:02 The idea being: all you port is this mess (via asm, C, whatever) - and treat the entire mess as partially-compiled. 08:34:05 Naturally, once compiled, the actual "code" would be involate 08:34:07 yeah, but it's substantially more complex to write something to run these opcodes than one to run stack opcodes. 08:34:29 OK.. I'm not sure I follow, but I'm listening/reading. 08:35:52 hmm... 08:36:01 Near as I can tell, from a bit of reading around google: stack-oriented asm just conceals the regs. 08:36:33 sure. 08:36:53 so this way you lose all the advantages of concealing the registers. 08:36:59 As I only leave access to seven (00...07), I think we can hide any number more 08:37:20 besides making the VM more complex - if nothing else, it's more work to decode these opcodes. 08:37:31 I see what yer saying, but we still need RP, DP, SP, etc, no? 08:38:15 but they're internal - they're not really exposed to the "user" in any way. 08:38:44 wait... Are you thinking of using this for languages in general? Or just forth-likes? 08:39:01 hmm.. I'd have to see your suggested alternative. In general, forthish is just a Bonus. 08:40:02 I'd be perfectly willing to read input from you with the proper twist for stack-based. 08:40:16 --- join: _saon (i=1000@c-24-129-89-116.hsd1.fl.comcast.net) joined #forth 08:41:06 All I was thinking was "Screw it, let's emulate a bigendian non-intel/non-ppc/non-68000 type chip and we should AVERAGE something decent" 08:41:25 OK. I thought you just wanted to build a forth-like language on top of this. 08:41:30 I do. 08:41:44 Because in that case, all you're doing is adding another layer of overhead. 08:41:51 And, I will. But, This is how I 'think' in asmish 08:42:41 Instead of being able to straightforwardly generate stack-based bytecode from Forth, and then (if you want) having a backend that goes straight to register-based local asm/native, 08:42:57 no. Look... you define a word, but instead of a specific-cpu of native-code, or an indirect-layer specific to the forth, we compile this pseudoasm 08:43:15 your Forth compiler has to immediately translate to register-based code, and then you STILL need another translator to go to native. 08:43:46 right, but instead of compiling this pseudoasm, you could simply compile something that's practically indistinguishable from Forth in the first place. 08:43:53 It's more work to go to this pseudoasm. 08:44:00 Sure, and - I've said several times, If you want to recompose this idea stack-based, I'm listening/reading. 08:44:50 The point remains, forth itself is not really "asm" - it's about as high as C, but with more flexibility and less checking 08:46:23 OK, starting from there: very generally, C is like a higher asm. Instead of registers, it has named variables. 08:46:29 And, the way I'm trying to lay out these codes, a lot of stuff is either a vector thru a call/jmp array, or a case-cascade or an if 08:46:36 Right. 08:46:57 You can similarly remove all the high-level stuff from Forth and come up with something that could be implemented in hardware. 08:47:15 Which is what I'd like to target as a baseline, yes 08:47:16 Have you ever looked at any of the forth chips that are out there? 08:47:24 a few years ago. 08:48:55 It just doesn't seem like you get the low-level stack-based processor concept. 08:48:57 Please, please remember: I don't really care if interactive use is as slow as - say Gforth... What I want is at LEAST that, and the ability to send/recv "files" of this nature and even native-code compile them. 08:49:21 tathi: you may well be exactly correct - I've never really worked with any of them 08:52:33 I keep thinking, when I think stack-based, we need basically the full panoply of stack-gymnastics foremost. And then treat it all as an "array" for assorted ops. 08:53:02 And I don't see that you ever need to really treat it as an array. 08:53:34 oh, I'm thinking of like... R3, R2, R1, R0, etc. 08:53:49 I think of it like this: the top two or three elements are your "registers", and operations simply work on those instead of having to encode which registers to use in the opcode. 08:53:52 (R as in REG) 08:53:56 It makes your opcodes smaller 08:54:08 (because you don't have to encode arguments, except literals) 08:54:20 Hmm 08:54:35 It makes your VM simpler, because you don't have to decode which part of the opcode is actually opcode, and which is arguments. 08:54:47 That I sure agree with 08:55:08 So I don't see where it's a win to move to register-based. 08:55:21 register-emulated - even worse 08:55:46 If you have stack-based, you only have to translate Forth to register-based if you want to go to local-asm. 08:56:09 If you're emulating registers, then you ALWAYS have to translate Forth to register-based, which makes your Forth compiler more complex 08:56:32 sure, and for true native-compiling it would be acceptable 08:56:52 Hmm 08:57:46 I'm not even sure that it's simpler to translate register-based opcodes to local-asm. It might be, but you still have to to native register-allocation, which tends to be the tricky bit, so it might not. 08:57:52 OK.. Pause for a sec. What regs ARE needed, then? 08:58:41 seems like "flags", Data/Return base+offsets 08:58:53 OK, I don't disagree about needing DP, RP, SP, PC, (maybe a few more?) 08:59:08 yeah, and this is where I get confuzzled 08:59:18 I just think that with the stack model, they can be hidden. 08:59:35 The VM implementor needs to know about them, sure. 09:00:02 they can't be totally hidden, though - you'd still want push/pop, methinks 09:00:02 But I don't think they need to be accessible to programs running on top of the VM. 09:00:31 push/pop to where? 09:01:07 push at least a literal (which stack?) and maybe even pop from one stack to another for consumption? 09:01:52 hmm...I'm not saying this well. 09:02:06 yah, and I guess I am obtuse as well *sigh* 09:02:17 I'm trying, dude.. Really. 09:02:27 without stacks ( ds and rs) push and pop are not defined. 09:02:30 OK, how about this? 09:02:42 Most normal (register-based) processors have a PC register. 09:02:47 right 09:02:48 However, it's an internal register. 09:02:51 yep 09:03:03 When you're writing asm, you know that it points to the current instruction, or the next instruction, or whatever. 09:03:11 sure 09:03:16 And you can modify it by doing a jump, or a call, or a return. 09:03:20 yep 09:03:28 But you (usually) can't access it directly. 09:03:36 "return" and "call", of course know more 09:03:51 For instance, you generally can't grab the value of the PC and add to it and multiply it by something and then put it back in the PC. 09:03:57 right 09:04:31 All I'm saying is that I think the registers in a forth chip are like that. 09:04:44 I know. They'd have to be. 09:05:57 I'm mostly waffled/leery on thinking "work the stack, BE 'the stack'" - and I believe you are right. 09:07:01 OK, I think we might actually on the same page then :) 09:07:02 Otoh, it may well be that native-code alternatives are going to become one whore of an issue. 09:07:24 well, shit.. *sigh* 09:07:28 It just seems to me like you're trying to expose VM internals that are better left alone. 09:08:11 OK, please RFC on that attachment and I'll try to focus this weekend on switching my head into using the DS/RS for essentials. 09:08:22 I wish I had a good link to give you on translating stack-based to register-based. 09:08:37 yeah, I'm betting it is a real mess 09:08:55 But the only thing I can think of is Peter Knagg's thesis paper, and he uses some notation instead of just saying it. 09:09:04 No, actually it's pretty simple. 09:09:18 yeah, we don't want a new notation - I already suffer more than I can handle 09:09:35 tathi: simple to convert between them??? 09:11:37 well, relatively simple to compile stack -> register. 09:11:44 I've never really looked into the other way. 09:12:23 But when you parse an infix language, you kind of handle it as a tree, so it is a lot like a stack anyway. 09:13:43 You know what, the useful section of his thesis is pretty short, and I find it fairly readable. 09:14:09 http://dec.bournemouth.ac.uk/staff/pknaggs/thesis/index.html 09:14:19 Chapter 5, especially sections 5.5 and 5.6 09:14:22 uh-huh.. Hmm. Well, I'll take a look at "preverting" the opcodes. Feel free to suggest other flags, ops or regs. I plan to add a Float-stack and MAYBE a string-stack. 09:14:37 loading 09:17:11 hmm 09:17:49 getting the whole thesis - I agreed with 5.5, anyway 09:19:06 5.6 is the interesting part. May be a little obtuse, but I think the code examples give a good idea what sort of thing he is talking about. 09:19:27 could be.. Will have to read it thru 09:21:46 Personally, I think the "stacks" are - internally - just arrays or backwasswards-arrays: w/o much point in pretending otherwise. 09:22:26 Granting, (of course), we don't want users treating them as such 09:24:07 For sure let me know what flags/compares/tests you can think of to cover the spectrum: my ideas of flags are all C anymore, and I can't scale-off too much rust from my ASM days. 09:29:59 --- quit: Robert ("leaving") 09:32:06 ok 09:34:15 --- join: Robert (n=robert@unaffiliated/robert) joined #forth 10:11:16 --- join: PoppaVic_ (n=pete@0-1pool47-11.nas30.chicago4.il.us.da.qwest.net) joined #forth 10:12:00 --- quit: PoppaVic (Nick collision from services.) 10:12:03 --- nick: PoppaVic_ -> PoppaVic 10:34:09 --- join: snoopy_17 (i=snoopy_1@dslb-084-058-170-058.pools.arcor-ip.net) joined #forth 10:41:41 --- quit: Snoopy42 (Read error: 145 (Connection timed out)) 10:41:54 --- nick: snoopy_17 -> Snoopy42 11:29:52 --- quit: PoppaVic ("Pulls the pin...") 12:43:20 --- join: sproingie (i=foobar@64-121-2-59.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth 13:17:07 --- quit: sproingie (Remote closed the connection) 14:12:05 --- join: thinfu (i=thin@bespin.org) joined #forth 14:12:05 --- mode: ChanServ set +o thinfu 14:12:42 --- part: thinfu left #forth 15:32:06 --- join: JasonWoof (n=jason@dsl092-169-094.wdc2.dsl.speakeasy.net) joined #forth 15:32:32 --- quit: JasonWoof (Client Quit) 16:12:56 --- quit: Topaz (Remote closed the connection) 17:02:50 --- quit: Quartus (Remote closed the connection) 17:30:10 --- join: aum (n=aum@60-234-156-82.bitstream.orcon.net.nz) joined #forth 19:45:44 --- join: Quartus (n=trailer@ansuz.pair.com) joined #forth 20:14:08 hi Quartus :) 20:14:17 --- quit: tathi ("leaving") 21:03:39 --- quit: saon ("leaving") 21:29:09 --- join: skylan (n=sjh@dialup-216-211-57-14.tbaytel.net) joined #forth 23:59:59 --- log: ended forth/05.10.08