00:00:00 --- log: started forth/05.07.30 00:23:38 --- quit: I440r_ () 01:49:21 --- nick: nanstm -> Raystm2 06:21:13 --- quit: madgarden ("?OUT OF DATA ERROR") 06:21:39 --- join: madgarden (~madgarden@London-HSE-ppp3546403.sympatico.ca) joined #forth 06:24:52 --- join: PoppaVic (~pete@0-1pool66-178.nas22.chicago4.il.us.da.qwest.net) joined #forth 06:25:09 G'day 06:25:14 Hi 06:25:22 hi PoppaVic, what's shakin? 06:25:31 Not much.. Wakin' up 06:27:01 what time is it? 06:27:14 0930 06:28:29 ANyway, I guess shortly I'll try to get some more codish-stuff done. 07:08:03 --- quit: Robert (Remote closed the connection) 07:54:56 --- join: JasonWoof (~jason@Herkamire.student.supporter.pdpc) joined #forth 07:54:56 --- mode: ChanServ set +o JasonWoof 07:56:42 lo, herk 08:04:06 hello 08:04:31 just asked my package manager (portage) what it would take to upgrade automake 08:04:42 said it would install about 10 packages 08:04:51 6 of them being various versiouns of automake, 08:04:54 a couple autoconf 08:04:57 and a couple wrappers 08:08:39 --- join: Robert (~snofs@c-cf78e055.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth 08:09:02 yep 08:09:17 Autoshit is an unholy whore and horror 08:10:11 I honestly gave up on using it several years ago. I bought their stupid book to try to do better, and have decided learning C from scratch iseasier. 08:11:36 I don't think I need to upgrade now. 08:11:50 the code I was trying to compile missed a header file (unistd.h of all things) 08:13:04 MISSING??? weird 08:13:32 sorry, I mean it was missing "#include " 08:13:58 I;m currently trying to xlate config.guess into C, and then considering config.sub 08:22:16 --- join: samc (~sam@203-114-131-49.inspire.net.nz) joined #forth 08:24:00 when you can translate that, reespect ;-) 08:25:17 --- join: tathi (~josh@tathi.bronze.supporter.pdpc) joined #forth 08:26:01 JasonWoof: yah, I hacked the ebuild for autoconf-wrapper or whatever it's called 08:26:08 so it would let me only install one version. 08:26:18 it's just the gentoo guys being totally stupid. 08:26:24 actually, it's proving easy - it's just 49K+ of horseshit for substring-tests 08:27:38 yeah, the stuff that autoconf does is actually pretty straightforward. 08:28:03 it's just that all the parsing nonsense takes a bajillion lines of code in sh :) 08:28:08 yeah, just ugly-assed and verbose crap-doodle, so far 08:29:00 afaict it just uses the C compiler to check if various libraries and headers exist. 08:29:14 of course, what you're trying to do, actually determine the ABI, is much harder :) 08:30:08 oh, did you figure out whatever you wanted me for yesterday? 08:30:18 yeah, so far I'm just HEADING that way.. I think some simple, old-fashioned text-based datafiles and a stupid C program anyone can try to build and run should do the trick 08:30:52 tathi: not as I recall, sorry about that - and I can't recall what it was, since here and #asm took off (finally) as they began to grasp the concepts 08:31:36 cool. Just thought I'd check. 08:31:56 s'ok, though - I'll headbutt that wall again, I am sure ;-) 08:36:47 tathi: I think I was seeking register-use for the ppc (and macosx is a powerbook variant as well), and looking for some test-code and ideas for a Virtual-CPU that would be fairly portable 08:39:15 I might have the Mach-O ABI docs around somewhere, but I haven't bothered reading them. 08:39:35 I wish I could remember that project that was doing a cross-platform assembler kind of thingy. 08:40:10 yeah, I found the headers (which helped), but I just _know_ that everyone else on the planet uses a different method 08:40:11 IIRC they found that if you do a RISC-ish thing it also works fairly well with x86. 08:41:10 you mean...mach-o is different than every other PPC ABI? Yeah. 08:41:15 well, I'd appreciate if you'd let the ideas percolate in yer subconcious. I just KNOW our issues breed issues when we are sleeping 08:41:22 yup :) 08:41:42 tathi: sure, and regs are used thus here, and are not there, and renamed foo over here ;-) 08:42:28 * PoppaVic knows it's those fuckin' "Third-Shift-Elves...." 08:46:51 --- join: nothingmuch (~nothingmu@yovalk.bb.netvision.net.il) joined #forth 08:49:01 is there a way to enable DOES> and CREATE to work without padding the word that CREATE makes such that there is enough space for either a return opcode, or a call to the DOES> body? 08:49:27 that's all predicated on the interpreter/compiler 08:49:47 well, the question is really: 08:49:59 is the code that DOES> compiles into the constructor word always destructive? 08:50:04 I'd be suprised if it was ever other that a way to emulate a call 08:50:07 that is not interpreter/compiler dependant 08:50:11 see defer 08:50:48 please explain that 08:51:17 : defer create does> @ execute ; ? 08:51:18 well, most forths have a word called 'defer' 08:51:22 nothingmuch: You could use indirect threading and change the word code address. (if I'm understading your question correctly) 08:51:23 nothingmuch: destructive meaning...? 08:51:47 tathi: that you compile code that makes a call the the generic over the code that returns to the caller 08:52:10 then yeah, probably. 08:52:16 even ASKING these sorta' things predicates a knowledge of the CPU, the ABI and the pcode 08:52:31 Robert: you mean if 'RETURN' is a word that deletes a stack frame instead of an opcode which writes the stack head into the instruction pointer? 08:56:36 Are you asking for the definition of indirect threading now, or something else? 08:56:52 well, i think i misunderstood your question 08:57:17 I'm not even sure I understood yours. 08:57:20 wait, are you writing a Forth, or just trying to use one? 08:57:21 in indirect threaded code let's say the first N codes ar reserved for opcodes 08:57:28 tathi: hehe =) 08:57:32 writing one, ofcourse 08:57:41 oh, lord 08:57:56 ah, ok. I totally misunderstood that. :) 08:58:51 Robert: so anyway, the opcode that returns to caller, and a non BSR call to the "rest of the definition" (the generic code defined after DOES>) cannot be the same width 08:59:17 unless return to caller is an indirect call 08:59:25 which does manipulations on the return stack 08:59:50 no, that still doesn't work 09:00:00 yer assuming way too much 09:00:06 PoppaVic: yes, i know 09:00:19 but i'm allowed to, it's my forth after all 09:00:28 i can make it as drunk as I like =) 09:00:28 Sorry, dinner time now. 09:00:42 either it's call-threaded, func-threaded, or you have a compiler and struct that can tell whom does what to whome 09:01:12 either way, my point is that under any threaded code model returning to caller and continuing to the generic word are not the same width 09:01:22 nothingmuch: trust me, ok? This is nontrivial... There are ASSORTED models around 09:01:50 PoppaVic: all I'm asking is whether there is a model where both can be a single opcode 09:02:03 it doesn't matter unless your compiler is compiling fields-of-opcodes, which is almost insane 09:02:12 every time i come in here to ask a question you say "i can't answer that, there are too many options", instead of saying "one option is: ..." 09:02:15 you might as well not answer 09:02:24 * PoppaVic sighs 09:02:49 look, i have something that works 09:03:01 and you might as well buy a few fuckin' books,ok? Stop blaming US because you can't ask coherent questions with a comprehensive background. 09:03:13 i'm not blaming you 09:03:32 FIG was the first, F83 was next, then FPC tweaked the pc's 09:03:46 what the ... ? time for reading backlog.... 09:03:46 so, within those alone there are about a dozen models 09:03:56 PoppaVic: please pleas listetn 09:04:03 nothingmuch: I am trying 09:04:05 the question was very specific 09:04:09 No 09:04:12 --- join: I440r (~foo@rrcs-24-242-160-169.sw.biz.rr.com) joined #forth 09:04:12 yes 09:04:14 the question is insane 09:04:34 is there a model under which you can define "CREATE" such that the code it compiles. 09:04:42 e.g. pushing some space on the stack 09:04:45 every goddamned forth is a combo of mc and engine/interpreter 09:04:48 pushing a pointer to some space 09:05:02 and then returning 09:05:07 not every CPU even *HAS* a stack 09:05:20 PoppaVic: if you don't have anything useful to say, why do you even bother? 09:05:25 ... have that code overridable by DOES> without weird alignment 09:05:31 * PoppaVic sighs 09:05:41 my bad tathi, he's all yours 09:05:49 on a shared code/data heap, under every model i've read about, you can't 09:05:56 that's why I'm here asking 09:06:02 if you really expect me to go buy every forth book 09:06:06 read it cover to cover 09:06:07 hmm...I could explain what isforth does, maybe 09:06:11 find out what is implemented 09:06:12 or I440r could :) 09:06:16 and then come here and ask 09:06:24 then there is no point in answering at all, right? 09:06:24 exactly what is the "weird alignment"? 09:06:44 well, since returning to the caller and going to the generic code and then returning 09:06:48 tathi: come on now, after the shot across my bows you need to do better ;-) 09:06:49 or doing a tail call to the generic code 09:07:06 are a different width 09:07:27 anyway, I think that in a bunch of forths, create makes a word that has a 'call dovariable' 09:07:33 and then the data. 09:07:39 yup 09:07:42 the word needs to be padded, so that any allotting after CREATE is pointed to by the word CREATE compiled 09:07:43 dovariable takes the return address from the call, and puts that on the stack. 09:07:55 ah 09:07:57 so then does simply patches the 'call dovariable' to be 'call dodoes' 09:08:00 okay 09:08:13 depending on the engine 09:08:14 that makes sense =) 09:08:14 err, call "does> body" 09:08:16 something like that. 09:08:41 that's essentially what I do in RetroForth 09:08:52 nothingmuch - any time you create ANY word its always created as a variable 09:08:53 PoppaVic: well, yeah, he just asked for one model that works 09:09:09 if its a colon definition the "call dovariable" is patched to be a "call nest" 09:09:35 if your creating a does> word then its slightly more complex (tathi over simplified it :) 09:09:39 I440r: not in RetroForth :) 09:09:41 herkforth works on osx 09:09:48 : constant create , does> @ ; 09:09:52 the mach-o header is different than elf 09:10:33 does> is an immediate word and it will compile a call to ;code and then create a "call dodoes" immediatly after it 09:10:43 : creates an entry point (with no code following), then passes control to ], which is the compiler 09:10:44 so the above definition for constant will actually look like this 09:10:48 : constant 09:10:59 create , ;code call dodoes @ ; 09:11:16 tathi: my only concern is that we did not know his platform or engine, and he wanted a "generic answer" popped out for his engine. 09:11:27 when you run constant it will create "A variable" - the ;code then patches the "call dovariable" to be a call to the "call dodoes" !!! 09:11:32 PoppaVic: no i did not 09:11:48 dodoes then has two items on the stack. 09:11:55 i wanted to learn of some ways it can be done. It's already working for me, i wanted a more generic model 09:11:56 the address to interpret and teh address of teh constant 09:11:58 the only difference in the ABI for mach-o that I've noticed, is that if the syscall fails, it skips the next instruction 09:11:58 JasonWoof: yeah, and it's a bitch-dog. They have executable, static-libs, shared-libs AND "modules" (plugins) 09:12:13 linux doesn't do that, it sets flags, or r3 or something 09:12:15 oop, bbl 09:12:21 JasonWoof: I sure hope you learn more from it than I did 09:12:33 PoppaVic: what'd you did? 09:13:10 I was experimenting with libs, THAT works fine. Still no idea what the compiler is generating/system needs, etc. Just vague ideas 09:13:15 err... are you guys talking about the Mach-O ABI or the Mach-O file format? 09:13:30 tathi: I think he means the fmt 09:14:11 JasonWoof: I think there are more ABI differences once you get away from the kernel. 09:14:21 I did find an obscure, powerbook-only header that helped explain more... But reliance on such beasts is quite dangerous 09:14:51 the varargs calling convention is quite different from sysv, I think. 09:16:21 I just do syscalls, and generate the exe file header 09:16:26 syscalls are different 09:17:03 oh, interesting 09:18:10 I'd love to see what yer generating and why, eventually. I've about concluded we need a lib for generation for something like a dlopen loader 09:18:40 he's just generating a binary that only relies on the kernel (i.e. only does syscalls). 09:18:47 ahh 09:19:04 I don't do linking 09:19:14 I'd hate to rewrite wrappers for all syscalls 09:19:23 I just made the smallest header I could, that loads one section (the whole file) and starts executing it 09:20:31 PoppaVic: huh? You have one routine that does syscalls for you (or compiles code to do a syscall). 09:20:52 and then you just have a word for each syscall that gives the syscall # (and probably the number of arguments) 09:20:58 afaik, you still need to ABI for syscalls. 09:21:15 ..this assumes more than C itself 09:21:22 oh, sorry. 09:21:28 yeah, I'm assuming herkforth. :) 09:21:40 or IsForth, I guess. 09:21:42 so'k, yer just posed to leap on me today ;-) 09:22:11 ah, sorry, I'm forgetting where you're coming from again. 09:22:34 A whole lot of stuff is based on common-assuptions. I know, it's hard to break the mold 09:22:35 herkforth runs on Linux and OS X, IsForth runs on Linux (x86 and PPC) and FreeBSD (x86). 09:23:04 when you only have two or three platforms, and your only ABI interface is syscalls, it's no big deal to rewrite it for each. 09:23:04 right, I have a herkforth tarball (somewhere) 09:23:32 well, again.. syscalls - from asm (which) from C (whose). 09:23:43 anyway, I was just trying to say that, given that you're only doing syscalls, the "syscaller" code should all be in one place, so it's (relatively) trivial to rewrite. 09:23:49 hell, it's becoming a chore to ascertain whom is doing what and where 09:24:00 tathi: sure, and I agree 09:24:02 and then all your words which use syscalls should just work (though you might have to change the syscall #) 09:24:31 ..It SHOULD be trivial, but the deep-end code becomes a real mess of "conditional compile" 09:25:02 Yah, I haven't really solved that problem. 09:25:25 when I think of syscalls, I think of the C headers... Then, I remember that every platform and cpu is a monster assumption. 09:26:14 the folks that are comfortable with autoshit usually find me tedious.. I find them to be insane and complacent ;-) 09:26:25 you do not need any c headers to make a syscall 09:26:45 yah, syscalls are the interface to the kernel. Usually different from the core C libraries. 09:26:49 I440r: gee, really? ;-) Which platform and how> 09:26:53 But on unix systems, they tend to mirror them. 09:26:59 right 09:27:34 and yeah, autotools really don't do that much, but if all you're trying to do is write basic portable C programs, it's all you need. 09:27:39 syscalls are the *nix equiv to the old dos-codes, but the interface is a whole lot sloppier 09:28:11 C people seem to usually assume that you're not going to go poking into the lower level stuff 09:28:24 or that if you do, you'd better know what you're doing. 09:29:55 yeah. 09:30:02 It's sorta' depressing 09:30:23 otoh, so is sh and bash and java/php-type foo-foo 09:30:51 well, if you're not writing compilers or linkers or other language tools, you shouldn't need anything more. 09:30:59 and not too many people do that kind of stuff anymore. 09:31:09 I've tried for YEARS to work on convincing C-folks that C is just one more stage/level 09:31:30 tathi: those end up being more like excuses than reasons 09:31:56 ..same from the other ends, too 09:32:02 yeah, I'm just saying: for most of the software out there, autotools is perfectly sufficient. 09:32:29 even if it is an ugly kludge :) 09:32:35 sure, if the user is willing to devote more time to autoshit than to his original project-language 09:33:09 I dunno about that -- I've seen a few relative newbies add autoconf to their projects, and it didn't seem to be too hard for them. 09:33:20 but again, I've never tried myself, so I'm just talking out of my ass. 09:33:31 I still can't comprehend WHY the hell there is a NEED for the hell of autoshit, when it should be possible to define the api and abi all the way up and down. 09:34:13 well, again, abi is something that hardly anybody needs, so nobody has devoted the energy to do it properly. 09:34:25 and some of the people who DO need it are us weird Forth geeks who could care less. 09:34:48 grrr, gotta go, be back in 10-15 mins 09:35:27 hehe - understood across the board 09:45:40 --- quit: nothingmuch (Read error: 60 (Operation timed out)) 09:52:06 just seems like you're trying to do this from the top down. 09:52:26 I'd be writing something little that works on my box, and then expanding. 09:52:53 I;m not sure how the heck I'd bottom-up this mess 09:53:20 I think it's another issue of writing both-ends to write to the middle 09:53:44 it doesn't seem like you have concrete examples of how you would want to actually use this thing. 09:53:56 or maybe you do, and those aren't the problem 09:54:02 so you're discussing the other stuff here 09:54:08 --- join: nothingmuch (~nothingmu@yovalk.bb.netvision.net.il) joined #forth 09:54:50 tathi: I've tried to write a sample "script", and even parsed it.. I've concluded the issues begin so much lower that I need to consider the bottom-up 09:55:06 OK. 09:55:19 hell, the "bottom" ends up being the cpu\platform\os 09:55:49 This is why I sorta' baited and coaxed the #asm volken. 09:56:26 I think we are looking at a multi-level issue, and a simple textfile is often the answer 09:56:34 hmm...I guess I'm asking, what do you want to do that you couldn't do by just stealing the useful bits (the actual tests) from autoconf? 09:58:02 tathi: not sure at this point, have yet to try to decode the majority of autoshit.. Most seems more like serious noise. That, and text replacements/tests 10:00:11 A significant portion is the lack of a clear ABI-like textfile/compiler/interp - so, there is an awful lot of "catch-up" being done all over 10:01:12 yeah, seems like people are only just starting to consider this stuff. 10:01:40 right.. And, hell - in the days of z80/8080 cp/m it was NOT an issue. 10:02:08 and for "normal" programs, the tools we have are enough. 10:02:26 but now we have this explosion of languages, seems like people are starting to consider generic back-end/code generation stuff. 10:02:27 give yerself 10 cpu, 20 board-makers, and a dozen OS distro - now it all gets super-shitty 10:02:41 yes 10:02:51 not to mention language-interfacing 10:03:08 yah 10:03:48 the hillarious part is, this should have been an issue shortly after friggin' minix 10:04:14 I can see a makefile for 12 mainframes 10:04:58 but, NOT for 12 mainframes, 3 major OS, and 12 ucpu and 12 more OS 10:05:01 bah, stuff never seems to happen until a lot of people realize that they need it. 10:05:10 sure as hell 10:05:31 the chore is to get them to back off their 'scopes to see where you are coming from. 10:06:58 or you say everything is the same and build a 'layer' 10:07:02 well, you'd have to somehow put the benefits into their terms to convince them that you have something they need. 10:07:32 err, "that they need something more than what they have" 10:07:52 right 10:08:11 there are VM, interpreters, translators and compilers. 10:08:32 ..and every one of them is predicated on an ABI/API 10:08:58 it sorta' breaks down AT the cpu, but it does not have to do so 10:10:29 basically - near as I can tell - the ideas begin to fall apart when you expect the programmer to have an external source for information on a running platform 10:11:37 Anyway, it looks like I've familial issues now.. Cogitate lads ;-) Lemme' know what you dream up and cogitate ;-) 10:11:42 --- quit: PoppaVic ("calls it a day") 10:49:24 --- quit: Robert (Operation timed out) 10:53:26 --- join: Serg[GPRS] (~z@193.201.231.126) joined #forth 10:56:03 --- quit: Serg[GPRS] (Client Quit) 12:23:31 --- join: dto (~user@66.189.37.253) joined #forth 12:23:32 hi 12:40:40 --- quit: tathi ("work") 12:47:51 --- quit: samc () 14:03:20 --- join: danniken- (CapStone@ppp-70-249-187-211.dsl.ltrkar.swbell.net) joined #forth 14:24:21 --- nick: danniken- -> danniken 14:24:38 --- quit: swalters ("User disconnected") 14:24:50 --- join: swalters (~swalters@2416457hfc118.tampabay.res.rr.com) joined #forth 14:31:19 --- quit: Jim7J1AJH (Read error: 110 (Connection timed out)) 15:21:23 --- join: Topaz (~top@spc1-horn1-6-0-cust128.cosh.broadband.ntl.com) joined #forth 16:49:32 --- quit: Topaz ("Leaving") 16:50:37 --- quit: nothingmuch (Read error: 60 (Operation timed out)) 17:30:14 --- join: snoopy_16 (snoopy_161@dsl-084-058-129-159.arcor-ip.net) joined #forth 17:36:38 --- quit: Snoopy42 (Read error: 145 (Connection timed out)) 17:36:56 --- nick: snoopy_16 -> Snoopy42 18:40:36 --- join: aum (~aum@port-219-88-128-203.orcon.net.nz) joined #forth 19:27:57 --- quit: aum (kornbluth.freenode.net irc.freenode.net) 19:27:57 --- quit: swalters (kornbluth.freenode.net irc.freenode.net) 19:27:57 --- quit: madgarden (kornbluth.freenode.net irc.freenode.net) 19:27:57 --- quit: ccfg (kornbluth.freenode.net irc.freenode.net) 19:27:57 --- quit: cmeme (kornbluth.freenode.net irc.freenode.net) 19:27:57 --- quit: crc (kornbluth.freenode.net irc.freenode.net) 19:27:58 --- quit: skylan (kornbluth.freenode.net irc.freenode.net) 19:27:58 --- quit: danniken (kornbluth.freenode.net irc.freenode.net) 19:27:58 --- quit: I440r (kornbluth.freenode.net irc.freenode.net) 19:27:59 --- quit: warpzero (kornbluth.freenode.net irc.freenode.net) 19:27:59 --- quit: Raystm2 (kornbluth.freenode.net irc.freenode.net) 19:27:59 --- quit: virl (kornbluth.freenode.net irc.freenode.net) 19:27:59 --- quit: JasonWoof (kornbluth.freenode.net irc.freenode.net) 19:27:59 --- quit: dto (kornbluth.freenode.net irc.freenode.net) 19:28:00 --- quit: Snoopy42 (kornbluth.freenode.net irc.freenode.net) 19:28:00 --- quit: onetom (kornbluth.freenode.net irc.freenode.net) 19:28:01 --- quit: ianp (kornbluth.freenode.net irc.freenode.net) 19:28:21 --- join: swalters (~swalters@2416457hfc118.tampabay.res.rr.com) joined #forth 19:28:32 --- join: Snoopy42 (snoopy_161@dsl-084-058-130-216.arcor-ip.net) joined #forth 19:28:32 --- join: onetom (~tom@ns.dunasoft.com) joined #forth 19:28:32 --- join: ianp (~ian@inpuj.com) joined #forth 19:28:52 --- join: crc (crc@pool-70-110-171-69.phil.east.verizon.net) joined #forth 19:28:52 --- join: madgarden (~madgarden@London-HSE-ppp3546403.sympatico.ca) joined #forth 19:28:52 --- join: ccfg (ccfg@dsl-roigw3de0.dial.inet.fi) joined #forth 19:28:52 --- join: cmeme (~cmeme@216.184.11.2) joined #forth 19:28:52 --- join: skylan (~sjh@dialup-216-211-4-230.tbaytel.net) joined #forth 19:28:52 --- mode: irc.freenode.net set +o crc 19:29:12 --- join: aum (~aum@port-219-88-128-203.orcon.net.nz) joined #forth 19:29:27 --- join: JasonWoof (~jason@Herkamire.student.supporter.pdpc) joined #forth 19:29:27 --- join: danniken (CapStone@ppp-70-249-187-211.dsl.ltrkar.swbell.net) joined #forth 19:29:27 --- join: dto (~user@66.189.37.253) joined #forth 19:29:27 --- join: I440r (~foo@rrcs-24-242-160-169.sw.biz.rr.com) joined #forth 19:29:27 --- join: warpzero (~warpzero@wza.us) joined #forth 19:29:27 --- join: Raystm2 (~vircuser@ppp-70-248-32-135.dsl.rcsntx.swbell.net) joined #forth 19:29:27 --- join: virl (~hmpf@chello062178085149.1.12.vie.surfer.at) joined #forth 19:29:27 --- mode: irc.freenode.net set +o JasonWoof 19:45:04 --- quit: aum () 20:13:48 --- quit: JasonWoof ("off to bed") 21:45:01 --- join: sproingie (foobar@64-121-15-14.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth 23:36:18 --- quit: sproingie ("Konversation terminated!") 23:59:59 --- log: ended forth/05.07.30