From owner-freebsd-current Mon Dec 21 02:53:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA06548 for freebsd-current-outgoing; Mon, 21 Dec 1998 02:53:53 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from newsguy.com (smtp.newsguy.com [207.211.168.71]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA06543 for ; Mon, 21 Dec 1998 02:53:52 -0800 (PST) (envelope-from dcsobral@newsguy.com) Received: (from dcsobral@localhost) by newsguy.com (8.9.1a/8.9.1) id CAA12289; Mon, 21 Dec 1998 02:53:15 -0800 (PST) Date: Mon, 21 Dec 1998 02:53:15 -0800 (PST) Message-Id: <199812211053.CAA12289@newsguy.com> X-Mailer: Direct Read Email by Newsguy News Service To: mike@smith.net.au From: "Daniel C. Sobral" Subject: Re: BootFORTH - demo floppy Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At Mon, 21 Dec 1998 02:37:36 -0800, you wrote >> >> Most string words in Forth take their count from the stack, so it's one cell, >> not byte. I suppose FICL uses 32 bits integers as cells, right? > >/* >** Strings in FICL are stored in Pascal style - with a count >** preceding the text. We'll also NULL-terminate them so that >** they work with the usual C lib string functions. (Belt & >** suspenders? You decide.) >** STRINGINFO hides the implementation with a couple of >** macros for use in internal routines. >*/ Just to make sure there are no misunderstandings here, this does not invalidate my point above. I don't know where these "strings" are used (most likely, the dictionary), but, for instance, EVALUATE takes it's count from the stack, not from the memory (in fact, it doesn't even expect a count in the memory), and it is thus cell-limited in size. >I *think* that Ficl will have to move to using 64-bit cells, at least >on the Alpha (since it stores pointers in them). ANS Forth is perfectly capable of handling different-sized cells and characters. In the code I sent, for instance, "80 allot" would rather have to be written "80 chars allot", if I were doing anything but a hasty hack. >This is definitely something to take up with John Sadler. The whole >reason that it's an issue from my perspective is that there are some >cases where I can see it being desirable to be able to handle strings >longer than 255 bytes with the bootloader, and that means that the >scripting language has to be able to deal with them. Sure. As I said, there isn't anything expect COUNT, C" and WORD that use memory-counted strings (in the interface, at least), and you can easily stay away from those. >Thanks for the clarification. As I said, I really would like this to "work". Feel free to send me any questions. (As I said in another mail, real work from my part will have to wait for a hd.) -- Daniel C. Sobral dcs@newsguy.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message