00:00:00 --- log: started forth/05.08.27 00:10:51 --- quit: sproingie (Remote closed the connection) 01:30:46 --- join: aum (n=aum@60-234-156-82.bitstream.orcon.net.nz) joined #forth 02:12:14 --- quit: aum () 03:22:15 --- join: aum (n=aum@60-234-156-82.bitstream.orcon.net.nz) joined #forth 03:34:10 --- quit: JasonWoof (Read error: 110 (Connection timed out)) 04:27:25 --- quit: aum () 04:32:47 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 05:01:04 --- quit: tathi ("leaving") 05:46:01 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 06:59:20 --- join: PoppaVic (n=pete@0-1pool64-58.nas22.chicago4.il.us.da.qwest.net) joined #forth 06:59:53 G'day 07:00:39 good morning PoppaVic 07:00:50 howdy - are we having fun yet? 07:00:54 yes 07:01:20 always a good sign 07:01:22 * crc has initial turnkey stuff in RetroForth/Linux now 07:01:31 heh - cool ;-) 07:04:18 crc: you caught our discussion the other day then, eh? 07:04:23 no... 07:04:28 oh my 07:04:44 * crc goes to meme.b9.com 07:05:02 well, we did spend the last hour or so talking about turnkey/extraction/xlating into source-lang output 07:09:15 --- join: snoopy_16 (i=snoopy_1@dsl-084-058-143-117.arcor-ip.net) joined #forth 07:26:28 --- quit: Snoopy42 (Read error: 110 (Connection timed out)) 07:26:45 --- nick: snoopy_16 -> Snoopy42 07:30:17 Any of those logged args help you, crc ? 07:32:03 not yet 07:32:11 * crc isn't sure how to proceed from here 07:32:32 heh - I get that DAILY ;-) 07:32:50 heh 07:32:51 I've been glaring at pretty much the same code for 2 weeks 07:33:36 I've done that 07:34:19 Somewhere in this mess I've got some answers, more questions and I *STILL* lack a "plan" to really share with others. 07:36:03 I think my prob is that the mess extends from the bottom MC right up to the shells/tools *sigh* 07:42:30 --- join: JasonWoof (n=jason@c-65-96-120-126.hsd1.ma.comcast.net) joined #forth 07:42:31 --- mode: ChanServ set +o JasonWoof 07:42:38 lo jas ;-) 07:42:49 hi 07:43:31 hey, I just reworked my ELF header example so it doesn't use hard-coded addresses 07:43:41 hehe, bastard ;-) 07:43:53 now it lets the linker set the base address, so it'll still work even if they change it. 07:44:08 neat 07:44:10 I can't use ELF lately, and I wish we had examples for it and mach that made sense 07:44:42 * tathi knows all about making ELF executables :) 07:44:46 sounds a little cleaner than not using the linker at all 07:45:01 yeah - linkers are really a necessity 07:45:03 yeah, it reads better as well 07:45:16 Where is this code at? 07:45:25 on my hard drive :-P 07:45:29 oh 07:45:35 +) 07:45:46 * PoppaVic spanks hissef 07:46:20 I figured out macho well enough to generate a header with one section 07:46:30 I've always been fairly perturbed about the lack of a lib for generating .o or .so-type files 07:46:57 I can tell. you're the perturbed type ;) 07:47:38 yah, when Not sighing over unsatisfying solutions, I get peeved about all the gymnastics other solutions require. 07:47:57 JasonWoof: I think it has to do with getting too old. 07:48:50 btw, crc sez he's been having fun 07:51:42 http://qualdan.com/examples/linking/elf.s 07:52:27 I don't think it's hard to make ELF .o and .so files, I've just never looked into it. 07:52:48 PoppaVic: have you looked at libbfd at all? 07:52:49 I've never been that low-down. 07:52:50 (just curious) 07:53:00 tathi: it won't help for non-linux, iirc 07:53:32 Yeah, I think I even snagged the tarball to a backup CD 07:53:49 I was more wondering if its API was any good. 07:54:00 what I saw was really ugly and obtuse 07:54:07 I was afraid of that. 07:54:41 I keep thinking we have GOT the tools, but coordinating them and testing FOR them consistently is a hurdle 07:56:23 tathi: nice code. 07:56:36 tathi: why's the example stuff set r18? 07:56:48 I can't understand why forth can't generate such stuff, though ;-) 07:57:33 JasonWoof: huh. no idea. 07:57:42 hehe 07:58:22 the rlwinm seems pretty silly too :) I thnk you could just do: li r18, -8 07:58:42 damn, this has gotta' be the ppc junk ;-) 07:58:51 I was probably checking bit numbering for rlwinm or something. 07:58:56 I took it out now. 08:00:09 beauty 08:00:40 might be nice to put code in there that finds the load address 08:00:47 tathi: the kick is: that asm-source is the base for an executable, right? 08:01:11 or can you: liw ehdr 08:01:13 PoppaVic: yeah. Just a minimal example. 08:01:23 JasonWoof: yeah, should be able to. 08:01:51 so... ld just xlates the .o to the equiv of an .exe 08:01:58 (in this particular case) 08:02:31 PoppaVic: should work on any PPC GNU/Linux system. Won't work on BSDs, because their ELF loaders are extremely picky. 08:02:34 yup. 08:02:59 yeah, I noticed Mac OS X was very picky 08:03:08 ok.. Thought so - no idea what "set up" the ld does for the _start_ code, myself - but it seems like a beginning 08:03:13 I was able to get it to load eventually though 08:03:19 JasonWoof: yeah, 3 modes, rather than 2 08:03:23 (the mach-o that is) 08:03:23 Well, you never know with Apple, they tend to rewrite a lot of stuff. 08:03:41 but FreeBSD won't run some ELFs that are valid according to the standard. 08:03:53 It requires you to have section headers, basically. 08:04:08 grrr 08:04:40 PoppaVic: in that example, ld just relocates the .o file to the appropriate base address, basically. 08:04:59 are sect-heads tough to generate, or are we talking about "a given sect-head restricts use"? 08:05:17 tathi: yeah, I thought that was what ld was doing 08:05:40 They're easy enough to generate. 08:05:54 it's just extra bother 08:05:54 ok, so it's the restricted size/i-o 08:05:55 But you can't (for instance) use brk() on anything without a data section. 08:06:03 ahhh 08:06:46 hmm... I don't seem to have a copy of my mach-o stuff on this computer 08:07:34 I'm tempted - weekly - to ditch macosx and just install a ppc linux variant *sigh* 08:07:48 And IIRC BSD wants your .text and .data sections to be separated by a page break, so sometimes you have to put padding in your executable. 08:07:58 PoppaVic: that's what we've done 08:08:12 Well, I never had OS X. 08:08:17 JasonWoof: understandable - it's very, very frustrating 08:08:22 The beta didn't run on this box, remember? 08:08:33 yeah, osx requires you to pad your executable to a 4K boundery 08:08:37 always thought that was stupid 08:08:45 tathi: yer talking ascii breaks/padding or some sorta' asm junk? 08:09:11 PoppaVic: he's talking about allignment 08:09:15 ahhh 08:09:26 there are .align pseudos 08:09:36 PoppaVic: it's easier to swap stuff in/out with mmap if things in the file are aligned to page (4096 byte) boundaries. 08:10:14 so the SysV ABIs (SysV defines ELF) require file offsets to match load addresses modulo the page size. 08:10:47 I'm just annoyed about the whole thing because I just want the whole file read into memory and executed 08:10:55 only thing I care to specify is how much memory 08:11:55 well, I can suffer a few extra param for reloc/extensible. It's the restrictions that get old 08:12:13 and the lack of a generator-library (of course ;-) 08:13:17 yeah. If I was planning to stick with Linux long term, I'd write one, but... 08:13:40 well written, it should not be a major butt-munch to port 08:13:59 it has 26 fields, plus some padding 08:14:04 tathi: what sys IS the target? 08:14:17 actually, I'd write the ELF part anyway, but I don't feel like coming up with a good API 08:14:33 I'd like to have my own system one of these days. 08:14:43 well, API's and docs are my forte' ;-) I always prefer writing a libto an app. 08:15:09 WHat I despise os autoshit. 08:15:15 os/is 08:16:24 I'm beginning to suspect that some judicious C, plus an asm->.o os/platform ABI, and a Makefile is prolly the best place to start 08:17:06 there we go again 08:17:53 absolute minimum mach-o header size that I could get macosx to load was about twice as big iirc. 08:17:57 checking 08:18:39 yeah, I think macho is a sloppy "we know better" elf-wannabe' 08:19:22 heh, scratch that, it's almost 4 times bigger 08:19:28 maybe because they want "backwards-compatability"? Never had an apple on my desk until this powerbook 08:19:47 84 bytes for ELF, 328 for Mach-o 08:20:00 hmm, how about drive block-size? 08:20:19 what about drive block-size? 08:20:27 is there a major diff? 08:20:54 oh, that's the other thing. mach-o your file has to be a multiple of 4K long 08:21:01 ahhh 08:21:15 PoppaVic: no, 68K Macs used XCOFF or COFF, or something, and I kind of think OS 9 used ELF. 08:21:22 ugh 08:21:23 I've only been aligning my ELFs to probably 4 bytes. if that 08:21:44 tathi: so, the prob is: they can't make a decision and get their head anally-removed? 08:22:57 I think the move from COFF to ELF made sense. 08:23:05 Not sure why they switched away from ELF 08:23:11 well, I'm no good at asm, drivers or high-math... But, if you need a C/H/docs nut, count me in on for-tathi or ostathi ;-) 08:23:38 I'd be happy with a header like this: 'FOOx' (magic bytes), system-type, memory required, code... 08:23:59 I am beginning, (sadly), to believe we need to do a lisp-ish answer. 08:24:10 they're using BSDs normal exe file format aren't they? 08:24:14 JasonWoof: or akin, yeah 08:24:23 dunno bsd 08:24:26 IIRC BSD will execute just about anything. 08:24:27 I thought the BSD elf loading stuff was part of the "linux compatibility" stuff 08:24:37 and mach-o was the native format 08:24:38 no, you can have BSD ELF files. 08:24:42 oh 08:24:46 huh 08:24:50 the difference is how you call a syscall (on x86, anyway) 08:24:52 oh? eh? wha?! 08:24:56 ohh 08:25:09 maybe they wanted some of the fancy stuff in the mach-o header 08:25:11 I think Apple was playing with the Mach microkernel for a while, so maybe Mach-O is related to that. 08:25:20 you can specify initial settings for the registers 08:25:40 playing with it for a while? isn't mach wath osx uses? 08:25:54 OK, check me if wrong (it was micro-K, btw) - but, we still need either a portable-toolbase, or a binary-base, right? 08:26:02 s/wath/what/ 08:26:27 JasonWoof: I'm not clear on that. I thought it was Mach, but Mach is a different kernel from BSD, so... 08:26:32 * crc though that OSX used XNU as the kernel 08:26:47 XNU? 08:26:52 they probably mushed it all together :) 08:27:04 is that like XSI? No idea where we are flowing ;-) 08:27:10 Basically Mach 3.0 with a BSD subsytem in the kernel 08:27:19 right 08:27:23 crc: ah, that would make a lot of sense 08:27:35 I bought this crap knowing it had a BSD core 08:27:54 ..past THAT, I'm quite disappointed 08:28:45 crc: do you cross-compile/asm the retroforth binaries or use autoshit? 08:31:37 yeah, macosx uses mach: Mach 3.0 microkernel, FreeBSD services 08:31:44 http://www.apple.com/macosx/features/unix/ 08:32:03 Near as I can tell, (from talk with lispers), Lisp began as C/asm and now Metacompiles itself everywhere. I can never see why the rest of us can't deal with that universe 08:32:46 JasonWoof: so "mach" is AKA "microK" ;-) 08:33:26 well, whatever it is - machosx does NOT make me wet myself 08:34:02 we're not as cool as hardcore lispers 08:34:12 Near as I can tell, all they do is integrate shit more publicly than doze 08:34:14 I'm better at lithping 08:34:50 PoppaVic: no 08:34:52 JasonWoof: I've always found that a poor excuse, since lisp preceeded forth. I think it's more ego/organizational 08:35:06 crc: oh? what? 08:35:18 I don't use autoshit at all 08:35:26 crc: good call ;-/ 08:35:40 crc: so, source-per or binary, then? 08:35:44 I use make (which I dislike) 08:35:51 PoppaVic: basically, yes 08:35:58 make is not earth-shattering but super handy 08:36:00 I have a few files that differ for each port 08:36:08 crc: as they should 08:36:19 (rf.asm, colors, blockio), but most are identical 08:36:27 OK.. That helps me cogitate... 08:38:21 basically, we need a makefile_c/asm (platform) source - including the metacompiler, OR the binary-package needs all the shit to ACT as the [meta]compiler there 08:38:50 humph 08:39:16 starting from the former, to create the latter "packages" is prolly the best solution. 08:40:08 crc: what externals, (other than goddamned sh), does the makefile require? 08:41:08 ..by this I mean things like grep/awk/perl/sed, etc 08:41:30 (oh, and gcc or CC) 08:41:55 sed, cat, grep, fasm, gcc (if you use generic or generic_ffi ports) 08:42:05 I've been building lists/datafiles and tests for weeks 08:42:43 why fasm? and wtf is a "generic_ffi port"? Near as I can tell, FFI is nearly impossible at this time. 08:42:44 optionally uses tr if you compress the whitespace with "make smaller=true" 08:42:57 generic_ffi has bindings over libdl.so 08:43:20 I used nasm for a long time, but it wasn't updated readily enough and the macro facilities were weaker than fasm's 08:43:22 never heard of the package, libffi sucksand ffcall is marginal 08:43:43 fasm and such mandates x86, does it not? 08:43:46 yes 08:43:55 rf is specific to x86 currently 08:44:02 where is the ffi source sited? 08:44:28 http://retro.tunes.org/rf8-dev-generic_ffi.tar.gz 08:44:44 ohhhhhh - it's your OWN ffi??? 08:45:22 accessing which other systems? 08:45:42 I didn't write libdl.so... 08:46:12 I have no source for that, but it's on every Linux box I've encountered using anything beyond a rescue floppy 08:46:15 oh. so - my bad... yer def of "FFI" varies from my understanding and dlsym-stuff 08:46:27 ok 08:47:16 crc: FFI, near as I can tell, is generally a lib and calls to generate/set up an asm or C call with args and returns back & forth is all 08:47:29 my wrappers over libdl.so provide for importing functions and calling them 08:47:38 it seems troublesome from some angles. 08:47:43 gotcha 08:47:59 hmmm 08:48:11 I call the proper libdl.so function, it maps in the function and gives me the address for it 08:48:27 then I setup the wrapper functionality to call/return from it 08:48:32 we are circling right back toward my minish, plus forth/vocs and pseudo-asm. 08:49:01 man, this whole thing gets soooo disturbing 08:49:37 I can see why lispers got to writing one binary and then metacompiler-distro 08:50:13 crc: are you requiring posix or what? 08:50:22 nope 08:50:44 well, pathing and dirs are strictly non-ansi, which iswhy I asked. 08:51:04 the build process assumes a posix-ish setup 08:51:14 ok, I figured that. 08:51:25 I want to get away from that at some point 08:51:28 ..ok... Lemme' get another brew and cogitate a few 08:53:14 hmm 08:53:39 At the very least, packages need to execute on targets. 08:53:58 folks forever forget targets vs hosts. 08:54:51 seems quite likely we need a c/asm/make/sh-ish executable to Metacompile. 08:55:34 I've seen this for awhile, but it needs limiting and codifying 08:56:34 crc: how are yer assumptions on devices, stdio and such? 08:57:51 I'm guessing, if you use make/sh then at least as deep as C - we presume an underlying libc(minimal) 08:58:08 key, emit, and type use stdin and stdout on the hosted ports 08:58:24 they're all vectored, so you can replace them if you need to 08:58:28 I mean for your building, though 08:58:52 ahh, nothing unconventional 08:59:02 I do a little redirection, but nothing fancy 08:59:04 It sounds like we can assume a simple C 08:59:17 ..at least the metacompiler, anyway 08:59:21 * crc does use /dev/zero in building the diskimage for retroforth/native, but that's as exotic as it gets 08:59:36 yeah, that IS "exotic", though 08:59:45 I can get by without it 09:00:01 ok, I can see a pattern... This was what was bothering me. 09:00:31 Is there any reason that we can't generate a C program to act as the inital metacompiler? 09:00:41 depends 09:00:48 on? 09:00:52 I don't metacompile :) 09:01:04 I know, I'm trying toget beyond that 09:01:14 I could replace the makefiles and whatnot with a simple C app 09:02:23 well, we might need to package the c in a core, but... What I'm pondering is leveraging C and libc at least on a host... What asm/platform/cpu (machine) specifics are being used in the target? 09:03:14 cpu: x86 09:03:24 that's for NOW 09:03:29 platform: linux, windows, freebsd, beos, 09:03:42 yer telling me yer mostly writing x86-asm 09:03:49 right 09:04:05 ok, and what - other than cpu - are your dependencies? 09:04:13 to run? 09:04:17 fasm, that I recall. 09:04:22 fasm to build 09:04:31 what devices, libs, syscalls, etc. 09:04:42 stdin, stdout 09:05:21 libs on Windows are kernel32.dll, on Linux, none, on FreeBSD, none, on BeOS and Generic, libc, on Generic+FFI, libc and libdl.so 09:05:28 what gets linked in, if anything? What FHS-dependencies are involved? 09:06:12 syscalls needed are read, write, exit, open, close, and chmod 09:06:16 This all indicates, to me, that we keep doing the same sorta' half-assed shit I recall from my CP/M days *sigh* 09:06:34 crc... I think we might be able to do a lot better. 09:06:38 I try to keep the dependencies as few as possible 09:06:46 PoppaVic: how? 09:08:12 crc: well, for starters... Forth began as a "get it ported, burned and we have a shell" - this was FIG..Nowadays, folks seem to think like that AND with dependencies. - but can't see that forth is not an OS and should not mix data/calls to complicate it. 09:08:35 I think there may be a way to get the thing "portable" 09:09:41 Just out of a left-handed curiousity: can gforth build and run on yer platform? 09:10:12 I'm trying to ascertain limitations/requirements. 09:11:15 yes 09:11:20 ok.. 09:11:43 Hmm... Meaning goddamned autoshit is there, and gforth covered the bases. 09:11:59 ok... Lemme think a bit. 09:13:01 How much true ASM does a forth need? What funcs/vm-support? Where need it expect platform-support? 09:14:15 Depends 09:14:23 you can do a forth with little to no true asm 09:14:38 * crc thinks of atlast 09:16:33 yes, I know - but my point remains: where are you using asm and why? I'm thinking of the underlying ABI/systems. 09:17:21 I use asm for the primitives and the compiler/interpreter loops 09:17:31 Does your engine itself take over the CPU and regs? 09:17:40 take over? 09:17:55 abuse it, so that interfacing is unlikely. 09:18:08 I have a register model (esi is my data stack, eax caches the TOS) 09:18:19 ok... 09:18:27 code is compiled to subroutine threading with inlining of some primitives 09:18:33 So, you are roughing out a forthism CPU 09:18:40 sort of 09:18:44 interesting 09:19:04 FIG, FPC/F83 distro's did similar 09:19:42 I used FIG briefly, but never used FPC or F83 09:20:13 Is your asm-source so bound to the synthetic-CPU and RAM it can't be xlated? 09:21:04 looks like PoppaVic wants a translation tool 09:21:30 no 09:21:44 not that I'm aware of anyway 09:21:45 ok, I thought so 09:22:08 They could then use a C-call (or a perl-call) or whatever? 09:22:22 up/down or across 09:22:25 with a minimal amount of work, yes 09:22:29 ok. 09:22:34 * crc is happy with his current model though 09:22:58 Does retroforth really generate binary (exe-like), or are we talking 99% interpretive-compiler? 09:23:19 it doesn't compile to standalone applications yet 09:23:27 hey, dude - I'dlove to see a "picture" of the model in email ;-) 09:23:30 (outside of a few experiments I've done) 09:23:42 ok, so the turnkey stuff is elemental. 09:23:46 heh 09:24:08 * crc has never done any visual/detailed layouts of the model 09:24:15 turnkey stuff is raw and brand new 09:24:24 does the system recognize external libs/calls/args/returns? 09:24:46 crc: can retroforth do a gforthish "see func" ? 09:25:40 that is a feature 09:25:51 I'm close to having that 09:25:57 (optional, not built in) 09:25:57 inspect decimal 09:25:58 decimal: 09:25:58 808aa14: call 8048381 ; literal 09:25:58 808aa19: dd 10 ; 10 09:25:58 808aa1d: call 8048629 ; base 09:26:00 808aa22: jmp 808a9bf ; ! 09:26:07 ok, introspection is the first step to 'see' and exporting 09:26:11 right 09:26:31 I can resolve most of the stuff that's inlined, resolve addresses to names in the dictionary, etc 09:26:32 Retroforth is STC with tail-call elimination only? 09:26:37 no 09:26:38 ok, I think I have learned enough to be puzzled and quite interested. 09:26:45 I do inlining of some things now 09:26:50 "STC"? 09:26:52 Ah. Gets harder to SEE. 09:26:55 right 09:27:00 Subroutine Threaded Code, PoppaVic. 09:27:03 subroutine threading 09:27:04 ohhh 09:27:30 not a bad option, but not really "compact" 09:27:38 trades space for time 09:27:44 Quartus Forth's SEE maps the direct inlining back to names for all the kernel primitives. 09:27:48 I did a DTC (direct threaded) version once 09:28:20 I generally havebegun to believe it's a subengine+marker issue 09:28:39 Quartus: I have about 2/3 of the inlined sequences resolving to the names now 09:28:51 only portability and FFI cares 09:29:26 I rarely use SEE myself. 09:29:31 Very rarely. 09:29:44 oh, it's educational - but gforth sorta' hurts its value 09:30:01 a lot of gforth shows up as hex 09:30:19 in fpc and f83, it was SERIOUSLY useful 09:30:55 In gforth 6, it disassembles. 09:31:26 oh.. Never seen that, everytime I look for an upgrade I get ignored... Must be goddamned appleshit 09:31:54 see drop 09:31:54 Code drop 09:31:54 ( $40285C ) mov dword ptr 4168E0 , ebx \ $89 $1D $E0 $68 $41 $0 09:31:54 ( $402862 ) add esi , # 4 \ $83 $C6 $4 09:31:54 ( $402865 ) add ebx , # 4 \ $83 $C3 $4 09:31:55 ( $402868 ) jmp dword ptr FC [ebx] \ $FF $63 $FC 09:31:57 ( $40286B ) xchg eax, eax \ $90 09:31:59 end-code 09:32:01 sorry. Big blast there. 09:32:04 $ gforth -v 09:32:04 gforth 0.5.0 09:33:05 folks tend to forget pcode is generally reversable. 09:33:43 ..and asm, given a zero-start, is reversable ;-) 09:34:14 Likewise in Quartus Forth: 09:34:15 see drop 09:34:20 0 move.w (a4)+,d7 = DROP 09:34:23 2 rts = EXIT 09:34:23 Further... Folks tend to forget as well that HUMANS want to 'see' - interactive and slllooow. 09:34:39 just wrote an assembler for our new VM fovium in herkforth 09:34:49 * PoppaVic sees a shitload of hexdump 09:34:53 output opcodes for: "1 2 + dup * exit" 09:35:15 I checked the bits in a hexdump, and it appears to be correct 09:35:39 tathi's going to continue debugging the vm implementation after lunch and see if he can get this to run 09:35:58 JasonWoof: man, I hate that so many of us veer NEAR wtf I've been advocating for several decades *sigh* 09:36:24 PoppaVic: if you want it to be exactly the way you want it... do it yourself :) 09:36:36 PoppaVic, I'm still not clear on what you're advocating. 09:36:45 JasonWoof: bastard ;-) 09:37:42 Quartus: I think it begins with a forthish shell, and advances to decent FFI & a sythentic-assembler. But, that's my current take. 09:38:24 I'm just about convinced that 99% of the reason for direct asm is either limited tools/platform or perversions. 09:38:24 ZZ 09:38:43 sleep on, dufus 09:38:47 oh or rather un-ZZ :) I have been asleep 09:40:22 PoppaVic: some people really do prefer asm 09:40:31 Quartus: near as I can tell, almost all asm-related forthish code is just there to synthesize a cpu.. or help FFI - and C does much the same... ANd worst: the latter (at least) doesn't want to publish an ABI 09:40:32 as a programming language 09:40:54 JasonWoof: sure, and some feel perl or php is The Best - not my prob. 09:41:42 And you define ABI as what? 09:42:00 I think forth has always been so damned nitched/grassroots we have both an opening and and a lack of support 09:42:24 Quartus: the ABI is the FFI info to get to and from one binary to another 09:42:34 On the same platform. 09:42:38 yes 09:42:46 target/host are a higher issue 09:43:23 Two different C compilers on the same platform could possibly have different ABIs. 09:44:35 yeppers 09:44:50 normally that would suggest a cross-compiler 09:45:09 So how would a lonely binary indicate its ABI? 09:45:21 we have almost as many "infra-platform" issues as "intra-platform" 09:46:09 Quartus: well, usually ala' elf/mach/whatever loaders or file-magic - a binary is either cpu-executable or interpretable 09:47:06 Quartus: I'm just trying to get a workable handle on the mess, and frankly forthers are more likely to understand than asm or c-heads 09:47:11 Ok. So what do you mean when you say that C doesn't want to publish an ABI"? 09:47:45 it doesn't - there are no decent structs/funcs for stack-frames and such - we are not SUPPOSED to know.. 09:48:40 further, C (and inline asm) don't care to structure regs/use/preservation/volatile/save-me 09:49:13 all of these have a bearing, and I am beginning to think they can be codified. 09:49:35 ..at least as a record/of-file.for.... 09:50:39 So archeologists far in the future will be able to run SOL.EXE on their own computers? :) 09:51:17 Quartus: yer sounding like an asm-head ;-) 09:51:49