00:00:00 --- log: started forth/02.12.25 01:05:12 --- join: MrReach (~mrreach@209.181.43.190) joined #forth 01:06:25 hihi! 01:07:13 Hey! 01:07:19 And good morning. 01:07:24 onetom: Haha, no f21 :) 01:07:34 how are you? 01:07:38 onetom: However, I got some chips to play with Forth on. 01:07:47 Quite OK... just woke up. 01:07:50 And over there? 01:07:51 which would those be? 01:08:11 Hitachi SH3 by any chance? 01:08:13 Just a few microcontrollers. AVR and an 8051. 01:08:16 No :) 01:08:19 bummer 01:09:10 Feel free to donate various hardware to me ;) 01:09:28 hmmm ... I wonder if one could make a living doing nothing but writing forth assemblers of various flavors 01:09:36 what do you think? 01:10:09 I'd donate a Jornada similar to my own if I knew you'd write a decent forth for it 01:10:09 Depends on how much money you need. 01:10:14 heh 01:10:35 Honestly, I don't know a thing about the market for Forth assemblers - if there is any. 01:11:20 just a stray though 01:11:28 I'll just make a cheap "assembler" out of Forth primitives. 01:11:46 yep 01:12:14 With these wonderful beasts I have here, I might as well be lazy and waste a few percent of their processing power for simplicity. 01:12:18 once you've got a good framework/structure, it's pretty easy to port to a new chip 01:12:48 Yes, that's another advantage. 01:12:56 AND, exactly what I'm about to do. 01:13:18 the forht method of using created words to store bytes and DOES parts to bit flip is insufferably hard to decipher, IMO 01:13:39 but makes for very compact code 01:14:57 Well.. how many of these primitives will you need? You could use MachineForth and maybe a few hardware-specific operations for the machine you're working on. 01:15:33 If the part to have to code this way is small enough, you might as well write good comments for it ;) 01:15:52 heh, if you're gonna write an assembler, go ahead and provide all the instruction set and operand variants 01:16:01 otherwise you'll just irritate your users 01:16:37 unless you're the only user, in which case you can only blame yourself 01:18:15 do you prefer "structured" assemblers or the more conventional label type??? 01:18:35 Hm. 01:19:07 I think traditional assemblers which support the whole instruction set should have a good syntax. 01:19:13 NASM is an example of this. 01:20:17 However - since I am the only used, I might as well decide that I don't need all instructions and all variants of them. 01:20:31 And that I might as well inline the basic Forth words. 01:20:38 only user* 01:22:56 heh 01:24:07 I prefer label type assemblers myself ... the source seems easier to read 01:24:49 Sure, if it's assembly you want. 01:25:11 I really enjoy programming in e.g. NASM, but I think it might be a bit overkill for some purposes. 01:25:40 yes, featuritise 01:25:48 but at least the basics are fairly simple 01:26:23 Single-pass or multi-pass? 01:26:41 NASM or Forth assemblers? 01:26:56 Forth assemblers are nearly aways single-pass 01:27:17 and I'm not sure about NASM ... multi-pass, logically 01:27:46 it waits until it's read all the source, THEN writes the output file, so multi-pass is convenient 01:27:59 NASM is two-pass. 01:28:29 Are Forth assemblers able to make forward references? 01:28:40 yes 01:28:45 How? 01:28:55 there are several methods of trickery to accomplish this 01:29:16 one is to use a list of unresolved references 01:29:25 and then patch them as they become known 01:30:33 I like the simplicity of the Forthish way for "forward references". 01:30:42 with structured assemblers, the IF leaves an address on the stack to resolve with THEN or ELSE, just like H/L forth 01:30:51 Yeah. 01:31:45 --- join: icefox (~sheath@63.218.224.221) joined #forth 01:31:56 Hi there. 01:32:04 Hey. 01:32:05 greets, icefox 01:32:35 Hm. I saw some guy called "TheFox" before, but it wasn't Jeff. 01:33:14 he used to call himself "JFox" on irc, I think 01:33:26 I wouldn't know. 01:33:34 Not when he was here. 01:33:52 what did he call himself here? 01:33:59 TheFox. 01:34:06 ok 01:34:44 Or, well.. "thefox" . 01:35:28 bye bye, everyone! 01:35:34 --- quit: MrReach () 01:35:35 Bye. 02:09:31 I haven't done much with Forth, but it seems to me that it's a little like assembler in form: The syntax is very easy for the machine to understand. Most other languages sacrifice that for syntax humans can understand. 02:09:45 Just thought it was an interesting insight. 02:11:28 --- quit: icefox () 04:16:56 --- join: Speuler (~Speuler@mnch-d9ba4dbb.pool.mediaWays.net) joined #forth 04:17:02 Hey Speuler. 04:18:07 'morning 04:19:08 has the red-dressed white-bearded avatar of capitalism be nice to you ? 04:19:45 been 04:22:08 Yes. 04:22:45 He gave me some electronics made by chinese slaves for my support to the capitalistic community. 04:23:10 ah. a quicker computer :) 04:23:23 Not really. 04:23:39 More like 10 MIPS microcontrollers. 04:23:49 But I did get my mom's old computer. 04:24:08 Linux doesn't want to use the 3c509 NIC :-/ 04:24:28 It detects it, and the card works in Windows, but Linux can't use the network. 04:24:58 sure 04:25:04 3x509 does work 04:25:14 ? 04:25:24 used linux with a 509 myself 04:26:42 Oh. 04:26:44 So have I. 04:26:50 Got it on a computer in the basement. 04:26:59 I wonder what the problem might be. 04:27:11 Since the card is obviously working. 04:27:25 that's an isa card 04:27:39 maybe interrupt routing 04:27:43 bios setup 04:45:06 --- join: Serg_Penguin (~Z@nat-ch1.nat.comex.ru) joined #forth 05:16:06 --- quit: Serg_Penguin ("changes cd-rw drive") 05:19:47 --- join: Serg_Penguin (~Z@nat-ch1.nat.comex.ru) joined #forth 05:41:37 --- quit: Serg_Penguin (Read error: 60 (Operation timed out)) 05:48:56 --- quit: lament ("mental mantle") 06:30:18 --- join: Serg_Penguin (~Z@nat-ch1.nat.comex.ru) joined #forth 06:30:54 Hey 06:41:41 can't decide ? 06:42:31 Decide for what? 07:01:52 come or go 07:10:01 --- quit: Serg_Penguin ("gotta run...") 09:38:02 --- quit: OrngeTide (Ping timeout: 14400 seconds) 13:13:32 --- quit: Speuler (Remote closed the connection) 13:37:12 --- join: mur (ammu@baana-62-165-189-165.phnet.fi) joined #forth 14:49:46 --- join: Speuler (~Speuler@mnch-d9ba4dbb.pool.mediaWays.net) joined #forth 15:56:10 http://www.webwareindex.com/tutorials/ 15:56:33 hm 15:56:52 hi mur 15:57:40 looks like a very handy index 15:59:12 * mur checkls 16:12:36 Hi there mur 16:12:49 hi here Robert 16:14:47 --- join: MrReach (~mrreach@209.181.43.190) joined #forth 16:15:04 hihi! 16:17:41 hi mrreach 16:17:52 almoist put a typo there 16:18:01 mrroach 16:18:04 oh? really? 16:18:06 HAHA! 16:18:19 haven't come across that one yet 16:18:55 though I've had people apologise for calling me "MR" ... a medical abbrev for "Mental Retard" 16:19:31 seems difficult to associate you with that 16:19:49 that's why i'm never insulted by it 16:20:34 so what forth have you been thinking about recently? 16:21:00 have contributed a tiny bit to openbios 16:21:08 cool 16:22:05 they are at the point of thinking to meta-ize their interpreter 16:22:19 meta-ize? 16:22:26 meta-compile? 16:22:30 yep 16:22:45 what HAD they written it in? 16:22:47 strip the current interpreter (paflof), then rewrite the kernel 16:22:48 Hey :) 16:22:56 c++ :( 16:23:00 greets, Robert 16:23:06 hi the_rob 16:23:31 that must have been incredibly awkward 16:23:50 I thought an assembler of some type, for sure 16:23:58 and have started to look for some tools to put an xscale-forth together 16:24:09 you have? 16:24:16 or they have? 16:24:22 for metacompilers, is still fancy the concept of virtual asm 16:24:26 i have 16:24:36 i still ... 16:24:41 what is "xscale"? 16:25:22 developed from sa110 16:25:30 the new strongarm 16:25:52 * Speuler 's pda contains an xscale cpu 16:26:07 heh, wish mine did 16:26:14 400 mhz :) 16:26:45 I'm more than happy with the computing power of my current PDA ... but its i/o options really suck big green donkey dicks 16:26:47 its official name is i think pxa250 16:27:44 still haven't put linux on the pda 16:28:03 you haven't? or it hasn't been done? 16:28:16 i haven't installed it on the pda yet 16:28:33 have they gotten the whole 2.4 kernel into it yet? 16:28:43 (say, an 8MB machine?) 16:28:44 am still running around with microcrap 16:28:55 yep 16:29:11 what are minimum requirements? 16:29:29 less than what's offered by my pda :) 16:29:42 (got 64 mb ram, 48 mb flash) 16:29:51 well, yours is pretty new, so has lots of resources, relatively speaking 16:30:24 that's without any extension yet, memory card or similar 16:30:28 right now, mine is configured as 16MB ram, 16MB rom, 128MB flash card 16:30:39 there are 5 gb microdisks available :) 16:30:51 good grief! 16:31:02 do they fit into a flashcard slot? 16:31:14 or external? 16:31:33 pcmcia2, i think (double size pcmcia) 16:31:40 * MrReach nods. 16:32:29 I'm really disappointed that forth didn't make it into these devices in a major way 16:32:42 it's a perfect place to showcase forth's capabilities 16:34:16 are you intimately familiar with Java? I know you've used it 16:34:27 I have a question about libraries 16:35:18 my knowledge of java is limited. i have helped porting a standalone java, written in asm, and i've helped writing a forth oo layer, modeled after java 16:35:31 but i don't know how to program in java :) 16:35:38 EXCELLENT!!! 16:35:50 I was thinking exactly the same lines 16:36:12 specifically, how would one write a cross-platform binary in Forth 16:36:23 there's an open version of that forth oo thing, with the same interface as the one i worked on 16:36:26 everything works well until I get to libraries 16:36:59 libraries really seem to throw a monkey wrench into the works, no matter what approach I take 16:37:28 how does Java implement portable libraries? 16:38:13 precompiled bytecode should be pretty portable, and library-suited too 16:38:39 yes, but those in the libraries will load into random positions 16:38:53 does each library have a runtime lookup table? 16:39:00 ah. libraries, using other library functions 16:39:09 how are the bytecodes assigned? 16:39:43 those known to the java compiler are assigned to fixed values 16:39:53 well, yeah, that's often the point of OO design 16:40:02 i think, $b6 was dup 16:40:09 right, I would call those "kernel functions" 16:40:33 versus a "library function" 16:40:55 many forth primitives have java bytecode equivalents 16:41:24 but how is the translation done for the libraries, which might be loaded at any address? 16:42:03 if i understand the problem, it arises if a library function calls another library function 16:42:14 right 16:42:33 i don't know how it is commonly handled. 16:42:38 well, it's a problem that applies in application to library calls, too, I should think 16:43:32 *possibly* by searching once for function name when it has never been resolved 16:43:51 the only solutions I could think up had either huge runtime overhead, or huge load time overhead 16:44:23 Java chose the huge load time overhead, judging from the way it started up 16:45:34 take a function reference. 16:45:47 have it point to a string (and flag it as string, not address) 16:46:08 upon calling, determine its address, fix the call 16:46:33 next time it is called it uses the address 16:46:58 yes, rather like .DLL and .so files are organized? 16:47:09 you'll have an initial penalty for looking up the function 16:47:32 but non-trivial programs should tend to call a function several times 16:47:41 yes, but they don't all have to be looked up at once 16:47:48 nope. 16:48:19 you could choose to 16:48:29 ok, so in a java-like system ... 16:48:43 but you could also just leave it the the calls themselves to fix the function references up 16:48:50 one might have a 16 bit byte encoder ... 16:49:17 if the top bit is clear, then the function is a kernel function, no lookup is required 16:49:40 kernel function = bytecode ? 16:49:54 but if the top bit is set, then a double lookup is needed, one for the raw bytecode ofset, and one for the offset into the library 16:49:57 yes 16:49:59 or non-byte code base-lib function ? 16:50:14 does that sound right to you? 16:50:22 in the case of a kernel call ... 16:50:40 there would be a lookup in a table, then an assembly jump 16:51:14 but in a library, there would be a lookup in a similar table, then a nest into the bytecode interpreter 16:51:35 (and possibly a search/calculation) 16:52:08 why double lookup on byte codes ? 16:52:36 hmmm ... 16:52:49 do you intend to compile byte codes to adress references upon loading ? 16:53:14 I'm just thinking theoretically 16:53:36 no, but they would resolve to address references eventually 16:53:47 transparent to the loaded program 16:54:03 the bytecode is the "address" 16:54:15 when first called, they won't know where to go, and need a process to find the address 16:54:20 even if it is looked up at runtime 16:54:37 right, hopefully 16:54:48 have the unresolved address references point to the same function 16:54:55 I was thinking that the bytecode was an offset into a procedure table 16:55:08 indicated by the "unresolved" falg 16:55:15 flag 16:55:59 for example, the kernel will have N functions, always at the same place in the table 16:55:59 that function looks up function address from function name, and patches it into the function (if writable, non-rom etc) 16:56:21 so the kernel calls are pretty straightforward 16:56:29 yep 16:56:37 but an app would have its own localized talbe 16:56:41 table 16:57:01 with an entry for each know library call 16:57:06 known 16:57:14 why ? 16:57:38 for prommable programs ? 16:57:38 because the binary is shipped with a fixed bytecode set 16:58:12 it expects 0x0023 to call into the kernel 16:58:24 yes, but the java vm requires a set bytecodes, with a predictable value per supported function 16:58:30 and it expects 0x8023 to be a call into a library of some type 16:58:41 ah. 16:58:47 exactly, but how does that work with loadable libraries? 16:58:56 byte codes are represented differently than library calls 16:59:12 library calls are/can be represented by their address 16:59:16 well they don't have to be, but that is a convenience 16:59:44 there are not many byte codes unused in a java vm 16:59:45 an app will need a different set of lib funcs from other apps, and will want to use the same set of bytecodes 17:00:14 ok. so it uses the always same set of byte codes 17:00:37 bycode 0x80023 might call "OpenFile" in one app, and "OpenTCPSocket" in another app 17:00:57 that wasn't the case in the design i worked in 17:00:59 on 17:01:07 both of which would be looked up at first call from their respective library 17:01:17 oh, ok, how did yours work? 17:01:19 i doubt you have that flexibilty with java 17:01:49 well, Java somehow asignes bytecodes at runtime, doesn't it? 17:02:05 i took a java reference book, and there were the functions, and a byte code assigned to them 17:02:14 so i suppose that's standard for all java vms 17:02:17 must be 17:02:30 otherwise precompiled byte code wouldn't be portable 17:02:33 are you saying that Java doesn't allow for runtime loadable libraries? 17:02:59 a library function is not referenced by byte code 17:03:10 how is it referenced? 17:03:22 they USE bytecodes to implement their function 17:03:33 the lib functions are ref'd by address 17:03:51 the address is looked up at first call? 17:04:02 it looks like a literal in forth 17:04:15 a byte code for "call function", followed by the address 17:04:16 gotya 17:04:57 not very portable 17:05:21 when only using bytecodes in the lib function, no problem 17:05:55 if not, you *probably* would have to look up the address 17:05:57 yes, but the library might be loaded at any address 17:06:09 once, at least 17:06:23 so the address as shipped will be inaccurate 17:07:10 ok, let pretend we have an app, MyApp 17:07:22 for rommable code, consider a short ref, 16bit or so, into a table which contains the library function addresses 17:07:36 that is: 17:07:46 it requires the Foo library, and calls only Blah within the Foo library 17:07:49 byte code "call short lib fn" 17:07:57 16 bit lib fn index 17:08:14 pointing into table of lib fn addresses 17:08:33 ok, so each lib has its own bytecode table? 17:08:34 that table probably must be build upon loading, or during run time 17:08:59 no, not really bytecode 17:09:05 more a pseudo-bytecode 17:09:08 no, lib functions are not represented as byte codes 17:09:33 only the equivalent of forth primitives are 17:09:42 ok, so in JVM, lib calls are carefully distinguished from kernel calls? 17:09:57 from byte code execution, yes 17:10:05 well, not quite 17:10:15 it is an argument to one byte code 17:10:33 the byte code "call libray function" 17:10:46 expressed by the literal value 17:10:49 ok, and in the apps memory, there is a table enumerating the addresses of the various library addresses? 17:10:51 which can be the address 17:10:58 or a token/index into a table 17:11:15 that's implementation specific, i suppose 17:11:50 as the table, or otherwise library fn ref will be built dynamically anyway, 17:11:56 right, but the app needs to know the address of the offset lookup table within each library, which will vary 17:12:06 there's probably no need to standardize anything there 17:12:41 the app, or the implementation of bytecode "call libray fn" ? 17:13:01 the implementation of the bytecode 17:13:10 it needs to know two things ... 17:13:22 which library, and which function in the library 17:14:02 you may be able to leave out the first information 17:14:20 and still remain binary portable? 17:14:28 by putting all calls of all functions into one table 17:15:01 of all libraries? 17:15:22 if the name of the function is known at runtime, it can be resolved at runtime (once, i hope) 17:15:24 but then the load order of the libraries will effectively randomise the table 17:15:34 that's what I was thinking 17:15:42 true. but what would be the disadvantage ? 17:16:16 at first call, a lookup would be performed with lib and func name, and then the address stored into a table somewhere 17:16:30 that you can reference only 2^16 library functions with 16bit lib references :) 17:16:43 yes. 17:16:48 I'm thinking about what follows the bytecode for "call libray fn" 17:16:57 you could probably run (optionally) a pre-loader 17:17:14 which does the resolving once during program start 17:17:16 yes 17:17:28 should be easy to turn that feature on or off 17:17:34 that's only useful if you're not certain your libs are going to be there 17:17:53 it would prevent a runtime error in the middle of the application 17:18:13 and, if your (portable) program doesn't know how to address the lib call yet, except by name 17:18:57 ok, so what follows the "call libray fn" token, what does it point to? what does THAT point to? 17:19:30 i could imagine, a 16 bit token, as index or offset into a table, which in turn holds addresses of library functions 17:19:53 and if the address is not yet known? what is in the table? 17:20:03 nil 17:20:31 then how does the program find the lib/func name to do the lookup? 17:20:36 or, a pointer to the required library fn name 17:20:41 from another table? 17:21:09 how does it tell the difference between the two pointers? 17:21:34 the "name" versus "address" flag introduced earlier. 17:21:54 16th bit set means "not yet looked up"? 17:21:58 then, we thought about using that for the calling function, but could be used in the table too 17:22:16 like that, yes 17:22:31 yes, we seem to be converging on a prototype very similar to what I was thinking before 17:22:40 "not looked up, but pointer to function name known" 17:23:11 right, bit set means other 15 bits somehow points to lib and func name 17:23:12 msb set = "identified by name" , not set = "identified by address" 17:23:41 makes sense 17:24:15 actually, that could be made much faster by using null/address in the table we were discussing, and ... 17:24:41 0< versus 0= makes hardly any difference, if at all 17:24:58 using another table, which holds addresses of corresponding descriptor info 17:25:14 yes, but testing just the high bit is expensive 17:25:22 nope 17:25:23 oh, ok 17:25:31 you're right 17:25:37 most cpus have a flag for that 17:25:46 just as they do for 0 17:26:09 another table would be needed anyway, because we only have 15 bits in a 32 bit world 17:26:23 actually, 0= should be more effort :) 17:26:36 cpu tests many bits, rather than just one 17:26:46 right 17:26:59 two's complement assumed 17:27:57 have you looked at how the Component Object Model is implemented? 17:28:18 didn't get beyond the intention to do so 17:28:20 it's pretty neat, but hard to prototype within the app 17:29:28 when an object is created, your returned a simple address 17:30:02 the only thing you know about that address is that the first cell is a point to a table holding addresses of machine-code routines 17:30:29 routines are always referenced by number, never by name 17:31:47 there's never any ascii lookup of any type 17:32:23 oh, i remember, you can swap tables 17:32:34 giving another table base as reference 17:32:43 in JVM? 17:32:46 to present a different interface 17:32:54 no, COM 17:33:09 oh, yes, that is the difference in object classes 17:33:43 each object holds a pointer to the table of functions that manipulates it 17:34:13 it is the first cell of the object's data area, and you're not allowed to play with any other part of it 17:34:47 the neat part about that is that the object's class can be in ROM with no ill effects 17:36:29 --- nick: mur -> mur|away 17:37:03 the unfortunate part is that once the methods for a given class are "published" ... they are frozen for all time 17:37:38 --- nick: mur|away -> mur 17:37:42 that fixes the problem that microsoft was having with .DLLs 17:37:44 --- quit: mur ("MURR!") 17:42:48 personally, I think COM is an excellent model for Forth OO, but maybe not for portable binaries 17:43:22 one could setup a really fast forth dispatch or forth objects ... 17:44:56 : objDispatch ( ... meth adr -- ... ) DUP @ ROT CELLS + @ EXECUTE ; 17:46:03 expressing meth as offset, rather than as index, saves a few runtime cycles 17:46:41 * MrReach nods 17:49:00 also, one could contemplate the notion of early binding 17:49:04 hmmm ... there's a problem 17:49:32 each method must have a unique name 17:50:09 for example, the OPEN method in a file object cannot have the same name as OPEN in a socket object 17:50:29 SwiftForth solved this problem, but I can't remember how 17:50:34 names could be given as libname.functionname 17:50:41 yes 17:52:13 libname could be replaced against "pointer_to_libname" 17:52:27 beg parden? 17:52:57 rather than repeating libname for each function, keep it somewhere just once, and reference it by pointing to it 17:53:16 simpllifies comparison too 17:53:27 integer compares easier than string 17:53:59 libname would be a constant or value holding the initial address 17:54:19 to dispatch a method, one only needs its offset 17:54:29