00:00:00 --- log: started forth/01.11.27 01:01:27 * aaronl is away: sleep 10:13:17 --- join: Speuler (akhandel@preiselbeere.icafe.spacenet.de) joined #forth 10:14:03 hoi 10:49:38 --- part: Speuler left #forth 10:56:18 --- join: MrReach (~mrreach@209.181.43.190) joined #forth 10:56:42 --- mode: ChanServ set mode: +o MrReach 11:21:07 --- join: Speuler (akhandel@preiselbeere.icafe.spacenet.de) joined #forth 11:21:17 g'day 11:21:26 greetings 11:21:32 how are you? 11:21:41 tried 11:21:49 ahem 11:21:52 tired 11:21:59 heh, sounds like it @:^> 11:22:07 why so tired? 11:22:21 monday ? 11:22:44 over did yourself yesterday? 11:23:21 has cost me some effort to get up this morning 11:23:39 maybe the weather 11:23:48 --- mode: MrReach set mode: +o Speuler 11:24:02 thank you 11:24:09 no prob 11:24:45 did some catch and throw this morning 11:25:00 how is it turning out? 11:25:10 unfinished 11:25:19 when I did mine, I had probs getting everything all lined up, initially 11:25:34 took me three tries before I was happy with it 11:25:42 i take the implementation i did for psion as template 11:26:14 only, instead of putting the catch frame on return stack, i put it on user stack this time 11:26:17 heh, also, catch/throw are difficult to script test 11:26:33 Speuler: is that legal? 11:26:40 why not ? 11:26:50 just a sec, let me look it up 11:27:07 word called with catch is not supposed to access stack below anyway 11:27:10 or is it ? 11:27:16 locals, specifically, were not to affect the user stack 11:27:31 I'm not sure if the same restriction applied to catch frames 11:27:55 yes, they are allowed to access the user stack as deeply as they need 11:28:08 no real reason for putting it on userstack, except that it can be accessed easier. 11:28:30 just pop, instead of mov ..., [ebp] add ebp, cell 11:28:53 looked neater 11:29:21 maybe i move it to return stack 11:29:57 pity x86 has no autoincrement fetch (except lods and pop) 11:30:14 none on general register 11:30:36 I'll be damned! you found an ommision in the standard! 11:30:53 lods is supposed to be costly anyway on 386+ 11:31:27 it is ... the string instructions are strongly discouraged, and no longer optimised 11:31:43 if catch word may access user stack anyway, it is no ommission but just a mistake by the implementor 11:31:48 ok, do you have the ANS doc in front of you? 11:32:02 file:///U:/doc/dpANS_Forth/dpans9.htm#9.6.1.0875 11:32:05 gotta search them on the net first 11:32:19 i'm not behind my own machine 11:32:23 ok 13:32:42 --- log: started forth/01.11.27 13:32:42 --- join: clog (nef@bespin.org) joined #forth 13:32:42 --- names: list (clog Fare @nate37 @MrReach @Speuler) 13:32:57 but i'm inlined to use the runtime workaround 13:33:41 indeed 13:33:53 this would be SO much simpler with a metacompiler 13:34:19 probably 13:34:40 heh, dp would get incremented in real time for every byte you added 13:34:45 as longer is use nasm, as more i fancy the idea of going meta quickly :) 13:35:05 why not start with meta? 13:35:24 I would be *MUCH* more inclined to jump in 13:35:25 i want to use a forth i know well for a metacompiler 13:35:43 and the forths i know best are the ones i write 13:35:55 only, i don't have an own forth for linux 13:35:56 --- join: aaronl (aaronl@vitelus.com) joined #forth 13:36:00 actually, there is *NO* reason a metacompiler can't be written entirely in ANS 13:36:11 primitives ? 13:36:21 can be written, ok 13:36:24 forth assembler 13:37:02 if you'll do assembler/disassembler, I'll do the metacompiler 13:37:06 i mixed up "ANS" and "system specific" 13:37:39 and we can argue incessantly about the fine points of the resulting system 13:37:47 i could reuse some assembly subset i've written already 13:37:52 but we talked about that already 13:37:57 you want a complete assembler 13:38:00 yes 13:38:31 to tell the truth, I'm completely daunted by the Pentium instruction set 13:38:46 therefore i tend towards subset :) 13:38:53 just the important stuff 13:39:04 * MrReach grins. 13:39:13 no need to implement opcodes which are never going to be used ... 13:39:30 instead, other way around: 13:39:38 implement the ones which ARE used 13:39:55 it is inevitable that if we build this system and release it, some joker will use the one instruction we left out of the assembler, no matter how obscure 13:40:08 probably within weeks 13:40:23 but, at that point he could probably just load a third-party assembler 13:40:34 where are such things? 13:41:08 most x86 forth assemblers i know are x86 13:41:09 you know SOMEONE must have written a complete assembler by now ... where the hell is it? 13:41:24 winforth has a 386 asm afaik 13:41:32 486 13:41:56 but i'm not a fan of winforth style 13:42:13 neither am I ... complicated and undocumented 13:42:49 might be a good base, though 13:43:28 I'm thinking maybe I should simply close my eyes, hold my nose, and jump in 13:44:15 (and hope I don't drown in Intel docs) 13:44:45 it appears to me that operand(s) operandtype operand(s) operandtype operation may be a reasonable generic operand specification scheme 13:45:25 yes 13:45:29 where reg puts its own operand type on top of reg spec 13:45:39 although _operandtype_ is seldome used 13:45:47 and [reg] another operand type etc 13:46:03 it may help getting the thing somewhat more orthogonal 13:46:11 do you want to enumerate addressing modes here? 13:46:26 as far as useful, yes 13:46:38 helps operation to build its opcode from 13:46:50 ok, I'll do the easy one ... implicit operands ... NOP and CLC 13:46:58 RTS 13:47:10 RET, that is 13:47:27 ok, then there's one operand register direct EAX INC 13:47:40 and [EAX] INC 13:47:45 and [EAX] BYTE INC 13:47:48 and [EAX] WORD INC 13:47:50 and [EAX] DWORD INC 13:47:52 yes, one operand register indirect 13:48:14 what should [EAX] INC default to? 32 bits? 13:48:15 DWORD [EAX] INC may be easier 13:48:32 nope ... 13:48:48 [EAX] BYTE INC is ... 13:49:30 let's set it so that DWORD can be speced either before or after the [EAX] 13:49:30 shit. 13:49:49 it simply sets an operand size flag 13:49:51 2nd operand must be able to modify operand type of 1st operand ... 13:49:52 ??? 13:49:59 sometimes ... 13:50:06 example? 13:50:06 [EAX] AL MOV 13:50:10 [EAX] AX MOV 13:50:11 [EAX] EAX MOV 13:50:17 nope spec needed there 13:50:22 no spec 13:50:34 size implied by the destination 13:50:38 [EAX] BYTE EAX MOV --> "bummer" 13:51:05 as _should_ be the case with ALL two operand instructions, because the second must be a register destination 13:51:23 does such an instruction exist? 13:51:46 the last doesn't. it is a contradiction 13:51:50 there's two ways to do that operation ... 13:51:57 or maust be handled by a "smart" assembler 13:52:26 resulting into [EAX] BYTE EAX movzx 13:52:41 but i don't like smart assemblers 13:52:58 [EAX] BL MOV EAX EAX XOR BL AL MOV 13:53:01 or ... 13:53:15 [EAX] AL MOV CBW 13:53:25 CBW = convert byte to word 13:53:32 ooops 13:53:39 [EAX] AL MOV EAX CBW 13:53:55 your line can be written as movzx eax, byte[eax] 13:54:08 it does the zero-extension of destination 13:54:33 movezx? Move if Carry Zero ? 13:54:36 i use it with COUNT in toyforth 13:54:48 move, zero extending 13:54:53 oh, ok 13:55:12 then, in reverse polish, it might look like ... 13:55:35 BYTE [EAX] MOVZX 13:55:46 oops, gotta specify destination ... 13:55:57 BYTE [EAX] EAX MOVZX 13:55:57 yo again 13:55:59 ... resulting into [EAX] BYTE EAX movzx ... 13:56:11 15 lines above ... 13:56:33 *BUT* the original size can be infered from register name, thus ... 13:56:42 [EAX] AL MOVZX 13:56:47 [EAX] AX MOVZX 13:56:50 [EAX] BYTE AX movzx 13:56:52 [EAX] EAX MOVZX 13:57:10 [EAX] WORD EAX movzx 13:57:15 MOVZX always extends to 32 bits? 13:57:27 nope, to destination operand 13:57:40 so might extend to 16 bits? 13:57:44 blarg! 13:57:48 i *think* that is the case 13:58:02 * MrReach looks, brb 13:58:27 * Speuler drugs himself with coffee 13:58:45 swapping machines too ... 13:59:13 --- quit: Speuler (Remote closed the connection) 14:02:47 --- mode: MrReach set mode: +ooo nate37 aaronl Fare 14:05:11 --- join: speuler (l@tangerine.icafe.spacenet.de) joined #forth 14:06:22 you're right, destination can be either 16 or 32 bits 14:06:42 and source can be 8 or 16 bits 14:07:02 so let's spec the dest as the resulting size ... 14:07:31 BYTE [EAX] AX MOVZX 14:07:44 BYTE [EAX] EAX MOVZX 14:07:51 WORD [EAX] EAX MOVZX 14:08:12 these are noops ... 14:08:14 pardon me, but putting BYTE ahead of [EAX] can make things more difficult 14:08:19 because: 14:08:24 BYTE [EAX] AX MOVZX 14:08:31 or simple move, actually 14:08:49 --- join: qless (~qless@clgr000977.hs.telusplanet.net) joined #forth 14:08:52 will [EAX] expect a length modifier, or not ? 14:09:00 hiya, qless 14:09:06 yo hello dudes 14:09:07 how about ... 14:09:08 what about [EAX] BX MOV ... 14:09:29 hi q< 14:09:34 all modifiers operate on current operand, source or destination 14:09:41 when assembler reset ... 14:09:55 operand is source until the source register is specified 14:10:08 i mean, will [EAX] expect a value on stack, or not ? 14:10:19 so anything preceeding the [EAX] would modify source operand 14:10:40 what preceeds operand, is put on stack 14:10:55 I would use bit flags in variables, rather than stack operands 14:10:57 it doesn't modify itself, but signals need to modify 14:11:18 because the assembly coder is likely to do some stack juggling to calc operands 14:11:40 correct 14:11:52 putting the operand modifier into a var is an acceptable proposition 14:12:10 I would suggest keeping the stack clear, regardless of the effort 14:12:40 ALL operands though buffers/variables ? 14:13:04 it is not very intuitive but worth to consider 14:13:10 yes, if the only other alternative is to put it on stack 14:13:46 return stack might work 14:13:56 hmm 14:14:07 sounds to me like the worst place to put those 14:14:21 or, as kind of locals 14:14:22 seems so to me, too, but possible alternative 14:14:35 locals tned to be on a return stack frame 14:14:58 might as well use variables or alloted region 14:15:08 xactlz. no need for locals 14:15:17 globals would do fine 14:15:37 locals only apply wthin defs, most assemblers run in interpretive mode 14:15:42 except, need to reinitialize after any opcode 14:16:08 yes, reset-asm has been a commmon word in all assemblers I've seen 14:16:20 user variables, erase whole local user space in one go ... 14:16:37 no fuss. just flatten it 14:16:48 so size modifiers should precede operand specifiers? 14:17:26 should unspecified size default to 32 bits? 14:17:27 if kept in variables/bit fields, it wouldn't matter 14:17:50 modifies the same, regardless whether coming first or last 14:18:04 yes, but which is easier to read? 14:18:16 just the need to delimite first and 2nd operand 14:18:18 and which should the dissassembler produce??? 14:18:40 more rpn would be operand modifier 14:19:04 more readable may be modifier operand 14:19:17 as modifier serves as a kind of filter, 14:19:28 ones knows while reading already what to ignore ... 14:19:32 I think easier to implement if modifier comes first 14:19:45 instead of menthal-stacking whole thing, and filter afterwards 14:19:56 mental 14:20:02 not menthol 14:20:20 and assume that ALL modifiers affect source operand, unless source has already been speced, then all affect dest 14:21:16 i would find it very desirable if the asm detects and complains about illegal opcode/adressingmode/operand size combinations 14:21:26 instead of just assembling garbage 14:21:29 yes 14:21:42 but how much effort should be expended on such? 14:21:50 half an hour ? 14:21:55 * MrReach laughs. 14:22:42 manually checking all addressing permutations on just a single instruction could take 2-3 hours 14:23:38 maybe getting all mnemonics, all addressing mode combinations in a list, replace the variables against wildcards, and hash the results 14:23:53 do the same with input, 14:23:59 hash them, 14:24:11 substitute the variables, 14:24:20 and outta comes the opcode ... 14:24:28 beg parden? not sure about the hash, but ... 14:24:54 hash, as a uniform representation of different-sized strings 14:24:59 often, the bit fields use the same bit patterns as used to specify registers in the opcodes themselves 14:25:00 simplifies lookup 14:25:48 in which case, and empty 3-bit field might be %1000 rather than %000 14:25:49 need a description how to embed the variable component into the opcode ... 14:26:11 it's in the intel docs 14:26:35 hmm. we need to distinguish between "0" and "to be filled in" 14:26:35 although they get a little fuzzy how the addressing mode is specified within the instruction 14:26:59 that's why I used the extra fourth bit, if you look more carefully 14:27:08 there is a limited number of operation,operand,addressing mode combinations 14:27:39 but the numbe gets huge if you encode mov al,1 as different hash value than mov al,2 14:28:12 but mov al,*byelit* would do 14:28:18 byteliteral 14:28:19 what exactly would you hash? 14:29:01 the whole instruction, including non-variable operands (i.e. the ones not easily embeddable into the opcode) 14:29:46 "variables" would be literal, registers, 14:30:10 yoiu wouldn't use the CREATE (store base opcode) DOES> (manipulate base depending on opcode) paradigm? 14:30:26 ooops ... typo 14:30:39 yoiu wouldn't use the CREATE (store base opcode) DOES> (manipulate base depending on operands and addressing modes) paradigm? 14:30:56 nope, but "operation" normalize hash embed-variables 0 do c, loop 14:32:45 ok, so the nmenonic might supply the upper 6 bits, the source addressing mode the next 4 bits, etc? then used in lookup table to provide adress of routine to embed variables? 14:32:47 : normalize remove_superflous_spaces_and_delimiters extract_variables trim : 14:33:13 mnemonic is hashed too 14:33:21 as characters? 14:33:42 erg, that's crazy 14:33:44 from chars to hash value. the whole normalized line is 14:33:51 I'll have to think on that one a bit 14:33:54 thank you 14:34:19 i feel honoured :) 14:34:24 what about literals? 14:34:48 variables. extracted in process of normalization, reembedded in the opcode 14:35:02 1234 +[SI] EAX MOV 14:35:51 intel format for that would be MOV EAX,[SI+1234] 14:36:42 "mov *reg32* [*lit*+*reg16*]" 14:37:09 "mov *reg32* [*lit16*+*reg16*]" 14:37:22 ok, so in my example above, how would the assembler know that 1234 was a literal? 14:37:35 the normalizer would have to know 14:37:37 it might look like HERE Var @ - 14:37:48 yes, but HOW would it know? 14:38:44 "mov eax [tos+SI]" 14:39:47 "mov eax [n+SI]" 14:39:48 I was thinking : +[SI] offset ! _SI set-source indirect&offset set-mode ; 14:40:11 oh, stack pic ... 14:40:21 : +[SI] ( n -- ) offset ! _SI set-source indirect&offset set-mode ; 14:43:47 or maybe ... : mkoffsetmode: c, does> c@ set-source offset ! indirect&offset set-mode ; 14:43:51 and then ... 14:44:10 _SI mkoffsetmode: +[SI] 14:44:18 _DI mkoffsetmode: +[DI] 14:44:27 _BP mkoffsetmode: +[BP] 14:44:35 _SP mkoffsetmode: +[SP] 14:48:48 do you know of an easy way to output just the ip address of a network card, for script processing ? i mean, easier than text processing the output of ifconfig ... 14:49:28 it's right at the top of the ifconfig output, should be pretty easy 14:49:35 might check in /proc 14:49:42 which I'll do now 14:49:42 doing that right now ... 14:50:20 it is for the netboot clients 14:50:50 i try to have them use as many as possible common files 14:50:57 same fstab 14:51:33 now i put a script in /etc/boot.rc which does the client specific stuff. mounting private dirs etc 14:55:22 FOUND IT! 14:55:52 . /proc/net/dev 14:56:07 heh ... proc/net/dev Unknown command 14:56:19 no ip address in there... 14:56:30 just the interface name 14:56:40 isn't that what you were asking for? 14:57:14 then it's in ... 14:57:16 the only thing to distinguish machines are mac and ip addresses 14:57:19 . /proc/net/arp 14:57:29 looked already. 14:57:32 in much better format, I might add 14:57:45 then yours looks *VERY* different than mine 14:57:58 other machines are in, but not the ip address of the machine looking for its ip address 14:58:08 IP address HW type Flags HW address Mask Device 14:58:08 10.0.1.1 0x1 0x2 00:E0:D0:22:48:E8 * eth0 14:58:08 10.0.0.3 0x1 0x2 00:40:D0:02:78:EB * eth1 14:58:22 those are the ips of my two ethernet cards 14:58:35 duh! because it hasn't been assigned an ip yet! 14:58:40 it has 14:58:47 hmmm 14:58:51 got it from the dhcp server 14:58:58 mounted root dir alreadz 14:59:05 common root dir! 14:59:12 so the machine is up and talking on the net now? 14:59:14 must now mount its private dirs 14:59:21 running x 14:59:44 how odd 14:59:47 i have just ssh'd to it 14:59:49 which kernel are you using? 15:00:05 2.4.9 15:00:12 oh, I'm still 2.2 15:00:32 Inter-| Receive | Transmit 15:00:32 face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed 15:00:32 lo: 12821 129 0 0 0 0 0 0 12821 129 0 0 0 0 0 0 15:00:40 I should have thought of that before I went browsing through /proc 15:00:56 /proc/net/dev 15:01:02 no, that's /proc/net/dev 15:01:09 try /proc/net/arp 15:01:31 speuler: you want the ip in hex, or dotted quad? 15:01:33 not own, but other machines ip addresses in there ... 15:01:42 doesn|t matter 15:02:12 maybe /proc/net/route 15:02:43 no ip address, just iface 15:02:57 and gateway,dest, etc 15:03:13 or /etc/hosts 15:03:21 maybe i have to write a program for it ... 15:03:33 before i was scanning ifconfig output 15:03:43 but that was clumsy 15:03:52 gethostbyname() 15:04:49 i check out the debian channel ... 15:12:03 no reply. but the output of "host `hostname` looks good 15:14:44 no reply. but the output of "host `hostname` | cut -f 3- " looks good 15:15:26 cool 15:18:09 --- mode: MrReach set mode: +oo qless speuler 15:18:27 ah, the power of the dark side :-) 15:18:36 * MrReach snorts. 15:20:38 be back w/in two hours 15:20:44 --- nick: MrReach -> MrGone 15:21:18 export CLIENT=`hostname | xargs host | cut -f 3` in its final state ... 15:21:33 --- join: aum (~aum@210-86-60-227.jetstart.xtra.co.nz) joined #forth 15:24:45 hi - anyone home? 15:25:08 yes 15:25:19 no, not home 15:25:36 I have a general question - does anyone use any naming conventions for different types of words? For instance, different naming styles for constants vs variables vs colon-defined words? 15:26:09 I thought that a consistent naming scheme might make forth code more readable 15:26:39 hmmm 15:26:42 aum: you might copy conventions from Common LISP 15:27:00 : foo 10 ; 10 constant bar ... why different namings convention if words do the same ? 15:27:05 i kind of like the idea of using different colours on the console for different types of words 15:27:47 I like to code with a text editor 15:28:12 if a word returns a value, i don't care what kind of word it gave me the result 15:28:22 here's one really ugly convention I thought of... 15:28:23 ah 15:28:35 constants have trailing '@' to indicate that no '@' is needed 15:28:36 but the stack effect, i like to know of course 15:29:06 colondefs have a trailing ':' to indicate they are actual functions 15:29:11 pointer_to_mem constant xxx 15:29:12 xxx @ 15:29:18 no 15:29:26 pointer_to_mem constant xxx@ 15:29:29 xxx@ 15:29:33 vs 15:29:42 variable xxx 15:29:51 pointer_to_mem variable xxx 15:29:53 4 constant cell@ here cell@ + ? 15:29:53 oops 15:30:02 pointer_to_mem xxx ! 15:30:03 xxx @ 15:30:17 pointer_to_mem constant xxx 15:30:21 xxx @ 15:30:24 speuler: yes 15:30:31 no 15:30:48 1) pointer_to_mem constant xxx@ 15:30:50 xxx@ 15:30:51 or 15:31:07 2) variable xxx pointer_to_mem xxx ! 15:31:09 xxx @ 15:31:41 4 constant cell@ 15:31:42 C programmers often use case to distinguish things 15:31:45 eg 15:31:51 int functionName() 15:32:08 #define TOKENNAME 15:32:16 typedef struct ... StructName 15:32:38 why I ask about all this is... 15:32:59 verb: use a or several stack items 15:33:07 I'd save time in my code if i had a 'crutch' for remembering which words are constants, which are variables 15:33:08 noun: produces a stack item 15:33:19 adjective: modify stack items 15:33:27 cell drop 15:33:42 cell = noun , drop = verb 15:33:46