Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #39530 > unrolled thread
| Started by | humptydumpty <ouatubi@gmail.com> |
|---|---|
| First post | 2015-06-02 13:29 -0700 |
| Last post | 2015-06-10 12:16 -0700 |
| Articles | 7 on this page of 27 — 9 participants |
Back to article view | Back to comp.lang.forth
Extendable structure with inspection humptydumpty <ouatubi@gmail.com> - 2015-06-02 13:29 -0700
Re: Extendable structure with inspection anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-03 06:02 +0000
Re: Extendable structure with inspection humptydumpty <ouatubi@gmail.com> - 2015-06-03 08:27 -0700
Re: Extendable structure with inspection humptydumpty <ouatubi@gmail.com> - 2015-06-03 11:30 -0700
Re: Extendable structure with inspection Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-03 20:54 -0700
Re: Extendable structure with inspection "Alex McDonald" <blog@rivadpm.com> - 2015-06-04 09:11 +0100
Re: Extendable structure with inspection Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-04 04:43 -0700
Re: Extendable structure with inspection "Alex McDonald" <blog@rivadpm.com> - 2015-06-04 20:21 +0100
Re: Extendable structure with inspection Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-04 23:23 -0700
Re: Extendable structure with inspection "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-05 03:40 -0400
Re: Extendable structure with inspection "Alex McDonald" <blog@rivadpm.com> - 2015-06-05 15:31 +0100
Re: Extendable structure with inspection Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-05 08:48 -0700
Re: Extendable structure with inspection "Alex McDonald" <blog@rivadpm.com> - 2015-06-05 18:10 +0100
Re: Extendable structure with inspection albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-06-06 10:46 +0000
Re: Extendable structure with inspection hughaguilar96@gmail.com - 2015-06-05 17:53 -0700
Re: Extendable structure with inspection albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-06-06 10:56 +0000
Re: Extendable structure with inspection anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-06 16:00 +0000
Re: Extendable structure with inspection hughaguilar96@gmail.com - 2015-06-06 19:35 -0700
Re: Extendable structure with inspection "Alex McDonald" <blog@rivadpm.com> - 2015-06-07 10:51 +0100
Re: Extendable structure with inspection Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-08 23:24 +0200
SIZE RfD: Re: Extendable structure with inspection anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-09 07:56 +0000
Re: Extendable structure with inspection "Alex McDonald" <blog@rivadpm.com> - 2015-06-09 12:09 +0100
Re: Extendable structure with inspection Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-09 23:25 +0200
Re: Extendable structure with inspection "Elizabeth D. Rather" <erather@forth.com> - 2015-06-05 07:53 -1000
Re: Extendable structure with inspection hughaguilar96@gmail.com - 2015-06-05 17:34 -0700
Re: Extendable structure with inspection humptydumpty <ouatubi@gmail.com> - 2015-06-05 00:40 -0700
Re: Extendable structure with inspection humptydumpty <ouatubi@gmail.com> - 2015-06-10 12:16 -0700
Page 2 of 2 — ← Prev page 1 [2]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-09 07:56 +0000 |
| Subject | SIZE RfD: Re: Extendable structure with inspection |
| Message-ID | <2015Jun9.095600@mips.complang.tuwien.ac.at> |
| In reply to | #39643 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> Why would it be different? If you and Hugh cannot agree on a name
>> (and probably not on a common specification, either), that's certainly
>> not the fault of the standardization process; on the contrary, it
>> would explain why there is no progress in standardizing this feature.
>
>One of the problem of the SIZE proposal is that it's not well specified,
>which size. Aparently, Hugh just wants to know how much memory the
>allocater actually used, to allow cloning of lists without knowing what kind
>of data is inside the list. The other possible reason is to get what was
>actually allocated, which can be used to allocate strings and query the
>string length. The second usage is not possible if you just return the size
>of the actual memory chunk, but it's more useful.
The first usage would be useful for a region allocator.
The rationale for this thing is that the information is present anyway
(for FREE), and this holds only for the first usage.
>A memory allocater which works like the one of GLIBC could as well store the
>actual size, and not the padded one, as doing the padding is a simple
>operation, and it's not really harmful to do that on free() as well.
Ok, but we don't want to restrict the allocator to have this property,
do we? E.g., it would rule out buddy allocators. If we did, we could
just have two words: One for the requested size, and one for the
actual size.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-06-09 12:09 +0100 |
| Message-ID | <ml6hfo$i25$1@dont-email.me> |
| In reply to | #39643 |
on 08/06/2015 22:24:14, Bernd Paysan wrote:
> Anton Ertl wrote:
>
>>>But the above means that it will not be standardised as say a controlled
>>>word because those systems would have to admit that they can't implement
>>>it. "We implement the total of the Forth language" would no longer be
>>>true. So SIZE is kept out of the standard, and although you and I
>>>implement the same word, its name would be different.
>>
>> Why would it be different? If you and Hugh cannot agree on a name
>> (and probably not on a common specification, either), that's certainly
>> not the fault of the standardization process; on the contrary, it
>> would explain why there is no progress in standardizing this feature.
>
> One of the problem of the SIZE proposal is that it's not well
> specified, which size. Aparently, Hugh just wants to know how much
> memory the allocater actually used, to allow cloning of lists without
> knowing what kind of data is inside the list.
Exactly. It looked like an application aide memoire rather than a useful
feature of the language.
> The other possible
> reason is to get what was actually allocated, which can be used to
> allocate strings and query the string length. The second usage is not
> possible if you just return the size of the actual memory chunk, but
> it's more useful.
>
> In current GLIBC, it's fairly easy to implement SIZE:
>
>: SIZE ( addr -- len ) 1 cells - @ -2 cells and ;
>
> This hasn't changed since last time I looked at that, and that was
> when Hugh proposed his RfD. We could run an automated test which
> checks if this works, and if not, do a fallback on a solution which
> stores another cell. So I don't agree that it is prohibitive to
> implement that.
On Windows that doesn't work (but you probably knew that).
>
> A memory allocater which works like the one of GLIBC could as well
> store the actual size, and not the padded one, as doing the padding is
> a simple operation, and it's not really harmful to do that on free()
> as well.
>
> However, I could think of a very different way on allocating small
> blocks, especially on a 64 bit machine: I'd use mmap to grab a pretty
> large chunk of memory, and then subdivide it into e.g. 256 regions,
> each of which is responsible for 1..256*16 bytes objects. All objects
> greater 4k (one page) can use a different allocater, with more
> overhead per object.
>
> Computing the size of the smaller ones is easy, just subtract the
> start address of the big mmap area, and then extract the part of the
> address which indicates the size. One mmap on 64 bit Linux is limited
> to ~4GB, so if you run out of space and need another map, try to map
> it fixed on an address related to the previous map (that way,
> obtaining the size still works).
>
> malloc() would first check the free list for that size, to give you
> the last freed block of that size (that's good for cache locality to
> always re- allocate the last freed block; it has been touched
> recently); if the free- list of that size is empty, return the
> first-unused pointer for that size, and increment that pointer. free()
> just inserts the block into the free list for that size.
>
> In this scheme, it's not reasonable to store the actual requested
> size, i.e. you only get the size with padding. But the allocate/free
> operation could be really fast, and you don't waste any memory for
> storing the size. The implementation is trivial, size effectivity is
> very high (only the alignment padding overhead), and LIFO reuse is
> cache friendly and makes use-after-free bugs obvious.
>
This assumes a set of well ordered and user definable allocators. Windows
supports multiple heaps, uses different allocators for the same heap
dependant on the size of the request, supports reservation vs commit. A
Windows application that reserves but doesn't commit a huge chunk of
memory would be considered badly behaved. It requires backing storage,
builds page tables that are pinned but never referred to, and increases
TLB costs. To commit large areas would cause significant amounts of work,
since pages are zeroed for reasons of security; zeroing say 4GB is a non-
trivial start up cost.
One could argue that Windows could use malloc. That adds a library (the
CRT or C runtime) and a layer of obfuscation over the underlying Windows
allocators. Windows does not have system wide user definable allocators;
at bottom the Windows allocators are used by the CRT.
The language does not need to accomodate any of this beyond ALLOCATE and
FREE. A Forth library that works directly with ALLOCATE and FREE leaves
the implementor complete freedom as to how and what facility to use.
malloc for you, a SLAB allocator for him, HeapAlloc for me.
A suitable Windows implementation is left as an exercise for the reader.
Here's mine.
\ Windows heap function calls
1 import: GetProcessHeap
3 import: HeapAlloc
3 import: HeapFree
4 import: HeapReAlloc
\ The memory allocation code uses HEAP_GENERATE_EXCEPTIONS rather than
returning \ false on the stack. The reason is simple; crashing on a known
exception is \ easier than a crash further down the line on some other
exception. Early & \ informative is best. But if you want ANS behavior,
call ANS-MEMORY
create process-heap \ process heap address
0 , \ heap address
HEAP_GENERATE_EXCEPTIONS , \ flag should be zero to pass ANS test
: ans-memory ( -- ) [ process-heap cell+ ] literal off ;
: heap&flag@ ( -- fl heap ) process-heap 2@ ;
: allocate ( n -- a f ) heap&flag@ call HeapAlloc dup 0= ;
: malloc ( n -- a ) allocate throw_memallocfail ?throw ;
: free ( a -- f ) heap&flag@ call HeapFree 0= ;
: release ( a -- ) free throw_memrelfail ?throw ;
: realloc ( n a -- a' f ) dup>r heap&flag@ call HeapReAlloc
?dup if r>drop 0 else r> -1 then ;
: resize ( a n -- a' f ) swap ?dup if realloc else allocate then ;
: init-malloc ( -- ) call GetProcessHeap process-heap ! ;
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-06-09 23:25 +0200 |
| Message-ID | <ml7lii$5gn$1@dont-email.me> |
| In reply to | #39659 |
Alex McDonald wrote: > This assumes a set of well ordered and user definable allocators. Windows > supports multiple heaps, uses different allocators for the same heap > dependant on the size of the request, supports reservation vs commit. A > Windows application that reserves but doesn't commit a huge chunk of > memory would be considered badly behaved. It requires backing storage, > builds page tables that are pinned but never referred to, and increases > TLB costs. To commit large areas would cause significant amounts of work, > since pages are zeroed for reasons of security; zeroing say 4GB is a non- > trivial start up cost. I'm thinking of Linux. There, just mmap anonymous 4GB takes essentially no resources. All it does is to tell the page fault handler that this range is to be allocated when used. Including the TLB entries (no need to have TLB entries for yet unused memory). It takes 14µs on my machine to do so (and I can do it repeatedly, each time taking 14µs). -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-06-05 07:53 -1000 |
| Message-ID | <EqWdncwgSb5jfOzInZ2dnUU7-K2dnZ2d@supernews.com> |
| In reply to | #39560 |
On 6/4/15 8:23 PM, Raimond Dragomir wrote: >> I'd rather see you argue why you have this opinion, based on some >> experience. Packaging your opinion as "Forth philosophy" doesn't really >> help. > > I have this opinion based on my personal experience with Forth. If I like > something in Forth I say it, if I don't like something else I also say it. > I don't repeat anything from anyone else's opinions or what I read here or on internet. > And I don't feel the need to excuse myself every two or three words with "IMO" > and such things. > If what I say really helps someone, I don't know. > That's entirely fair, but generalizing your opinion as "Forth philosophy" is going a bit far. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-06-05 17:34 -0700 |
| Message-ID | <a3c78734-15d5-4852-af01-9e673d765cb5@googlegroups.com> |
| In reply to | #39597 |
On Friday, June 5, 2015 at 10:53:03 AM UTC-7, Elizabeth D. Rather wrote: > On 6/4/15 8:23 PM, Raimond Dragomir wrote: > >> I'd rather see you argue why you have this opinion, based on some > >> experience. Packaging your opinion as "Forth philosophy" doesn't really > >> help. > > > > I have this opinion based on my personal experience with Forth. If I like > > something in Forth I say it, if I don't like something else I also say it. > > I don't repeat anything from anyone else's opinions or what I read here or on internet. > > And I don't feel the need to excuse myself every two or three words with "IMO" > > and such things. > > If what I say really helps someone, I don't know. > That's entirely fair, but generalizing your opinion as "Forth > philosophy" is going a bit far. Oh, you're the only person who is allowed to do that? At least Raimond actually has some programming experience to back up his opinions --- you don't have any programming experience (other than COBOL) to back up your opinions, but yet you routinely spout drivel and declare it to be Forth philosophy. This thread is about structs. None of the Forth Inc. books discussed structs at all. SwiftForth doesn't provide FIELD. The data comma'd after a CREATE for use by the DOES> code is effectively a struct, but you don't seem to know that the fields can have names rather than just numeric offsets (none of the Forth Inc. books used named fields but they typically use CELL+ to step through the fields). Also, CREATE DOES> is the only example of packaged data that your books provide, yet these can't be nodes in a data-structure because CREATE only builds one at a time and gives it a name like an overgrown variable. There is no evidence anywhere to indicate that you know what a struct is or know that structs can be linked together by pointers to form a data-structure. You routinely describe PAD as the standard for temporary storage, and there is no evidence to indicate that you know what a heap is (although SwiftForth does have a heap). The only data-structure that "Starting Forth" provided was the array, and it wasn't general-purpose because it had to be rewritten with cut-and-paste programming for every primitive data-type (chars and words were provided in the book). In all likelihood, this represented your entire knowledge of data-structures in 1983 --- and you haven't learned anything since then, either.
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2015-06-05 00:40 -0700 |
| Message-ID | <e5e32f8a-2545-4919-a8db-f971b9788a56@googlegroups.com> |
| In reply to | #39552 |
joi, 4 iunie 2015, 06:54:11 UTC+3, Raimond Dragomir a scris: > miercuri, 3 iunie 2015, 21:30:24 UTC+3, humptydumpty a scris: > > marți, 2 iunie 2015, 23:29:09 UTC+3, humptydumpty a scris: > > > Hi! > > > > > > Without more words this content of 'struct.fs' + tests. > > > Verified under GForth 0.7.3, excerpt from command-line: > > > > > > --- > > > $ gforth -e "include struct.fs" > > > > > > \ Extendable structure with inspection. Wordlist based. > > > \ USAGE: see code between [IF] [THEN] > > > \ ----- > > > \ CONS: not a fastest compiling time > > > \ PROS: could use information at compile-time to compile for a faster execution > > > \ GForth 0.7.3 tested. > > > > > > \ Cure for improbable redefinition of '+' between > > > \ define structure locus and locus of fields use > > > VOCABULARY UNTAINTED > > > get-current ALSO UNTAINTED DEFINITIONS > > > ' + alias + > > > set-current PREVIOUS > > > > > > WARNINGS OFF > > > \ This text-macro is 'Base' dependent. Field compiled by this macro > > > \ should be used inside scope of a defined structure. See 'struct' definition. > > > : field ( offs size -- offs+size ; Text based macro ) > > > over >R > > > : R> ?dup > > > IF > > > S>D <# [CHAR] + hold BL hold #S #> > > > postpone SLITERAL postpone EVALUATE > > > THEN > > > postpone ; IMMEDIATE + > > > ; > > > \ For a safe use of fields defined by text-macro 'field', > > > \ preserve 'Base' that exists at time of structure definition. > > > \ Also cures "funny" '+' redefinitions. > > > : struct > > > get-current wordlist > > > dup CREATE , base @ , IMMEDIATE set-current 0 ( old-wid 0 ) > > > ( Now compile fields in structure-wordlist ) > > > DOES> > > > Base @ >R > > > dup cell+ @ Base ! > > > @ >order ALSO UNTAINTED > > > parse-name ['] evaluate > > > CATCH > > > PREVIOUS previous R> Base ! > > > THROW > > > ; > > > : end-struct ( old-wid size -- ) > > > S" VALUE SIZE" evaluate > > > set-current > > > ; > > > WARNINGS ON > > > > > > : extend ( "struct-name" -- old-base old-wid ) > > > Base @ get-current > > > ' >BODY dup > > > @ dup set-current >order > > > cell+ @ Base ! > > > ; > > > : end-extension ( old-base old-wid -- ) > > > set-current previous Base ! > > > ; > > > > > > : fields-of ( "struct-name -- ; structure inspection word) > > > ' >BODY @ wordlist-words > > > ; > > > > > > -1 [IF] sh cat struct.fs > > > HEX \ Test for independence of 'Base' > > > struct POS > > > cell field X > > > cell field Y > > > end-struct > > > DECIMAL > > > > > > cr ." Test for funny '+' redefinition: " > > > : + ." funny " + ; > > > > > > cr ." Test for inspection:" > > > cr ." POS constituents: " fields-of POS > > > > > > cr ." Test for scoping of defined structure at interpret/compile-time and fields compiling:" > > > VARIABLE X 1 X ! > > > CREATE Ob POS SIZE allot > > > 99 Ob POS X ! > > > 101 Ob POS Y ! > > > > > > : testX Ob POS X ? X ? ; > > > : testY [ Ob POS Y ]L ? X ? ; > > > : 2testY Ob POS Y ? X ? ; > > > see testX see testY see 2testY > > > cr testX cr testY cr 2testY > > > > > > cr ." Test for extending structure:" > > > extend POS > > > SIZE > > > cell field Z > > > TO SIZE > > > end-extension > > > > > > cr ." New POS constituents:" fields-of POS > > > > > > Create Ob2 POS SIZE allot > > > 2013 Ob2 POS X ! > > > 2014 Ob2 POS Y ! > > > 2015 Ob2 POS Z ! > > > : testZ Ob2 dup POS X ? dup POS Y ? POS Z ? ; > > > see testZ > > > cr testZ > > > > > > cr .s cr bye > > > [THEN] > > > > > > > > > Test for funny '+' redefinition: redefined + > > > Test for inspection: > > > POS constituents: > > > SIZE Y X > > > Test for scoping of defined structure at interpret/compile-time and fields compiling: > > > : testX > > > Ob ? X ? ; > > > : testY > > > 34389371752 ? X ? ; > > > : 2testY > > > Ob 8 + ? X ? ; > > > 99 1 > > > 101 1 > > > 101 1 > > > Test for extending structure: > > > New POS constituents: > > > Z SIZE Y X > > > : testZ > > > Ob2 dup ? dup 8 + ? 16 + ? ; > > > 2013 2014 2015 > > > <0> > > > $ > > > --- > > > > > > Have a nice day, > > > humptydumpty > > > > Hi! > > > > Healthier version, at previous version I forgot cure 'VALUE' > > for redefinition: > > > > --- > > $ gforth -e "include struct.fs" > > > > \ Extendable structure with introspection. Wordlist based. > > \ USAGE: see code between [IF] [THEN] > > \ ----- > > \ CONS: not a fastest compiling time > > \ PROS: could use information at compile-time to compile for a faster execution > > \ GForth 0.7.3 tested. > > > > \ Cure for redefinition of Forth words > > VOCABULARY UNTAINTED > > get-current ALSO UNTAINTED DEFINITIONS > > ' + alias + > > ' VALUE alias VALUE > > set-current PREVIOUS > > > > WARNINGS OFF > > \ This text-macro is 'Base' dependent. Field compiled by this macro > > \ should be used inside scope of a defined structure. See 'struct' definition. > > : field ( offs size -- offs+size ; Text based macro ) > > over >R > > : R> ?dup > > IF > > S>D <# [CHAR] + hold BL hold #S #> > > postpone SLITERAL postpone EVALUATE > > THEN > > postpone ; IMMEDIATE + > > ; > > \ For a safe use of fields defined by text-macro 'field', > > \ preserve 'Base' that exists at time of structure definition. > > \ Also cures "funny" '+' redefinitions. > > : struct > > get-current wordlist > > dup CREATE , base @ , IMMEDIATE set-current 0 ( old-wid 0 ) > > ALSO UNTAINTED > > ( Now compile fields in structure-wordlist ) > > DOES> > > Base @ >R > > dup cell+ @ Base ! > > @ >order ALSO UNTAINTED > > parse-name ['] evaluate > > CATCH > > PREVIOUS previous R> Base ! > > THROW > > ; > > : end-struct ( old-wid size -- ) > > S" VALUE SIZE" evaluate > > PREVIOUS set-current > > ; > > WARNINGS ON > > > > : extend ( "struct-name" -- old-base old-wid ) > > Base @ get-current > > ' >BODY dup > > @ dup set-current >order > > cell+ @ Base ! > > ; > > : end-extension ( old-base old-wid -- ) > > set-current previous Base ! > > ; > > > > : fields-of ( "struct-name -- ; structure inspection word) > > ' >BODY @ wordlist-words > > ; > > > > -1 [IF] sh cat struct.fs > > > > cr ." Test for funny redefinition of 'VALUE': " : VALUE ." WHAT A FUNNY VALUE!" ; > > 3 Base ! \ Test for independence of 'Base' > > struct POS > > cell field X > > cell field Y > > end-struct > > DECIMAL > > > > cr ." Test for funny '+' redefinition: " : + ." funny " + ; > > > > cr ." Test for inspection:" > > cr ." POS constituents: " fields-of POS > > > > cr ." Test for scoping of defined structure at interpret/compile-time and fields compiling:" > > VARIABLE X 1 X ! > > CREATE Ob POS SIZE allot > > 99 Ob POS X ! > > 101 Ob POS Y ! > > > > : testX Ob POS X ? X ? ; > > : testY [ Ob POS Y ]L ? X ? ; > > : 2testY Ob POS Y ? X ? ; > > see testX see testY see 2testY > > cr testX cr testY cr 2testY > > > > cr ." Test for extending structure:" > > extend POS > > SIZE > > cell field Z > > TO SIZE > > end-extension > > > > cr ." New POS constituents:" fields-of POS > > > > Create Ob2 POS SIZE allot > > 2013 Ob2 POS X ! > > 2014 Ob2 POS Y ! > > 2015 Ob2 POS Z ! > > : testZ Ob2 dup POS X ? dup POS Y ? POS Z ? ; > > see testZ > > cr testZ > > > > cr .s cr bye > > [THEN] > > > > > > Test for funny redefinition of 'VALUE': redefined Value with VALUE > > Test for funny '+' redefinition: redefined + > > Test for inspection: > > POS constituents: > > SIZE Y X > > Test for scoping of defined structure at interpret/compile-time and fields compiling: > > : testX > > Ob ? X ? ; > > : testY > > 34389371968 ? X ? ; > > : 2testY > > Ob 8 + ? X ? ; > > 99 1 > > 101 1 > > 101 1 > > Test for extending structure: > > New POS constituents: > > Z SIZE Y X > > : testZ > > Ob2 dup ? dup 8 + ? 16 + ? ; > > 2013 2014 2015 > > <0> > > $ > > --- > > > > Thanks to Anton Ertl for his insightful comments > > here on c.l.f., during development time of this > > structure lexicon. > > > > Have a nice day, > > humptydumpty > > What did you accomplished? Addressed your complaints: 1. You rants here that fields are global: >C structs are powerful, the fields are associated with the object. In forth >you cannot have this, fields are global. Forth structs are not so powerful. 2. In the same post you rant about inefficiency: >This is a classical example of inefficiency (like also the CONSTANT example implemented with create does>). The field word will do @ + at RUNTIME even if the offsets are well known at compile time, and this is a very common situation!. 3. You don't see how to use wordlists to make fields local. > You still need the structure name (not the > object name) to associate the following field with it. > You need to do this: Ob POS X Do you really understand what 'POS' is and what 'X' is? > A much cleaner and simpler way is just to prefix the field names with the > structure name! For example: Ob POS.X or Ob POS->X or anything you like. > So you want to revert to global field names that you previously criticized. :-) > I would have been impressed if you was able to do that: > Ob X Should I? LOL > This was the real discussion in some other thread: associate the field of > the structure with the object! Not only!
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2015-06-10 12:16 -0700 |
| Message-ID | <16c627a2-36b6-4bd9-b041-68aee99737cf@googlegroups.com> |
| In reply to | #39530 |
On Tuesday, June 2, 2015 at 11:29:09 PM UTC+3, humptydumpty wrote:
> Hi!
>
> Without more words this content of 'struct.fs' + tests.
> Verified under GForth 0.7.3, excerpt from command-line:
>
> ---
> $ gforth -e "include struct.fs"
>
> \ Extendable structure with inspection. Wordlist based.
> \ USAGE: see code between [IF] [THEN]
> \ -----
> \ CONS: not a fastest compiling time
> \ PROS: could use information at compile-time to compile for a faster execution
> \ GForth 0.7.3 tested.
>
> \ Cure for improbable redefinition of '+' between
> \ define structure locus and locus of fields use
> VOCABULARY UNTAINTED
> get-current ALSO UNTAINTED DEFINITIONS
> ' + alias +
> set-current PREVIOUS
>
> WARNINGS OFF
> \ This text-macro is 'Base' dependent. Field compiled by this macro
> \ should be used inside scope of a defined structure. See 'struct' definition.
> : field ( offs size -- offs+size ; Text based macro )
> over >R
> : R> ?dup
> IF
> S>D <# [CHAR] + hold BL hold #S #>
> postpone SLITERAL postpone EVALUATE
> THEN
> postpone ; IMMEDIATE +
> ;
> \ For a safe use of fields defined by text-macro 'field',
> \ preserve 'Base' that exists at time of structure definition.
> \ Also cures "funny" '+' redefinitions.
> : struct
> get-current wordlist
> dup CREATE , base @ , IMMEDIATE set-current 0 ( old-wid 0 )
> ( Now compile fields in structure-wordlist )
> DOES>
> Base @ >R
> dup cell+ @ Base !
> @ >order ALSO UNTAINTED
> parse-name ['] evaluate
> CATCH
> PREVIOUS previous R> Base !
> THROW
> ;
> : end-struct ( old-wid size -- )
> S" VALUE SIZE" evaluate
> set-current
> ;
> WARNINGS ON
>
> : extend ( "struct-name" -- old-base old-wid )
> Base @ get-current
> ' >BODY dup
> @ dup set-current >order
> cell+ @ Base !
> ;
> : end-extension ( old-base old-wid -- )
> set-current previous Base !
> ;
>
> : fields-of ( "struct-name -- ; structure inspection word)
> ' >BODY @ wordlist-words
> ;
>
> -1 [IF] sh cat struct.fs
> HEX \ Test for independence of 'Base'
> struct POS
> cell field X
> cell field Y
> end-struct
> DECIMAL
>
> cr ." Test for funny '+' redefinition: "
> : + ." funny " + ;
>
> cr ." Test for inspection:"
> cr ." POS constituents: " fields-of POS
>
> cr ." Test for scoping of defined structure at interpret/compile-time and fields compiling:"
> VARIABLE X 1 X !
> CREATE Ob POS SIZE allot
> 99 Ob POS X !
> 101 Ob POS Y !
>
> : testX Ob POS X ? X ? ;
> : testY [ Ob POS Y ]L ? X ? ;
> : 2testY Ob POS Y ? X ? ;
> see testX see testY see 2testY
> cr testX cr testY cr 2testY
>
> cr ." Test for extending structure:"
> extend POS
> SIZE
> cell field Z
> TO SIZE
> end-extension
>
> cr ." New POS constituents:" fields-of POS
>
> Create Ob2 POS SIZE allot
> 2013 Ob2 POS X !
> 2014 Ob2 POS Y !
> 2015 Ob2 POS Z !
> : testZ Ob2 dup POS X ? dup POS Y ? POS Z ? ;
> see testZ
> cr testZ
>
> cr .s cr bye
> [THEN]
>
>
> Test for funny '+' redefinition: redefined +
> Test for inspection:
> POS constituents:
> SIZE Y X
> Test for scoping of defined structure at interpret/compile-time and fields compiling:
> : testX
> Ob ? X ? ;
> : testY
> 34389371752 ? X ? ;
> : 2testY
> Ob 8 + ? X ? ;
> 99 1
> 101 1
> 101 1
> Test for extending structure:
> New POS constituents:
> Z SIZE Y X
> : testZ
> Ob2 dup ? dup 8 + ? 16 + ? ;
> 2013 2014 2015
> <0>
> $
> ---
>
> Have a nice day,
> humptydumpty
A new version with less gforth-isms and little more factored:
---
$ cat struct.fs
\ Extendable structure with introspection. Wordlist based.
\ USAGE: see code between [IF] [THEN]
\ -----
\ CONS: not a fastest compiling time
\ PROS: could use information at compile-time to compile for a faster execution
\ GForth 0.7.3, PFE 0.33.71 tested.
\ Uncomment if your forth implementation does not have 'parse-name'
\ CREATE parsebuf 32 allot
\ : parse-name ( 'name' -- ca u )
\ bl word count
\ 32 min >R
\ parsebuf R@ move
\ parsebuf R>
\ ;
\ Cure for redefinition of Forth words
WORDLIST CONSTANT UNTAINTED
get-current UNTAINTED set-current
' + alias +
' VALUE alias VALUE
set-current
: ++order ( wid -- ; )
>R get-order R> UNTAINTED rot 2 + set-order
;
: --order ( -- ; )
get-order nip nip 2 - set-order
;
\ Field compiled by this macro should be used inside scope of a defined structure.
\ See 'struct' definition.
: field ( offs size -- offs+size ; Text based macro )
over >R
: R> ?dup
IF
S>D <# [CHAR] + hold BL hold #S #>
postpone SLITERAL postpone EVALUATE
THEN
postpone ; IMMEDIATE +
;
\ For a safe use of fields defined by text-macro 'field',
\ preserve 'Base' that exists at time of structure definition.
\ Also cures '+','VALUE' redefinitions.
: struct
get-current wordlist ( old-wid wid )
dup CREATE , HERE 0 , ( post-it) IMMEDIATE ( old-wid wid a )
swap dup set-current ++order
0 ( old-wid a 0 ;Now compile fields in struct-wordlist )
DOES>
Base @ >R
dup cell+ @ Base !
@ ++order
parse-name ['] evaluate
CATCH
--order R> Base !
THROW
;
: end-struct ( old-wid a size -- )
S" VALUE SIZE" evaluate
Base @ swap ! ( old-wid ) \ fix-up current 'Base'
set-current --order
;
: extend ( "struct-name" -- old-base old-wid )
Base @ get-current
' >BODY dup
@ dup set-current ++order
cell+ @ Base !
;
: end-extension ( old-base old-wid -- )
set-current --order
Base !
;
: fields-of ( "struct-name" -- ; structure introspection word)
' >BODY @ >R get-order R> swap 1+ set-order words previous
;
0 [IF]
defined ]L 0= [if] : ]L ] postpone LITERAL ; immediate [then] \ PFE
cr ." Test for funny redefinition of 'VALUE': " : VALUE ." WHAT A FUNNY VALUE!" ;
3 Base ! \ Test for independence of 'Base'
struct POS
1 cells field X
1 cells field Y
end-struct
DECIMAL
cr ." Test for funny '+' redefinition: " : + ." funny " + ;
cr ." Test for inspection:"
cr ." POS constituents: " fields-of POS
cr ." Test for scoping of defined structure at interpret/compile-time and fields compiling:"
VARIABLE X 1 X !
CREATE Ob POS SIZE allot
99 Ob POS X !
101 Ob POS Y !
: testX Ob POS X ? X ? ;
: testY [ Ob POS Y ]L ? X ? ;
: 2testY Ob POS Y ? X ? ;
see testX see testY see 2testY
cr testX cr testY cr 2testY
cr ." Test for extending structure:"
extend POS
SIZE
1 cells field Z
TO SIZE
end-extension
' POS alias 3dPOS immediate
cr ." 3dPOS constituents:" fields-of 3dPOS
Create Ob2 3dPOS SIZE allot
2013 Ob2 3dPOS X !
2014 Ob2 3dPOS Y !
2015 Ob2 3dPOS Z !
: testZ Ob2 dup 3dPOS X ? dup 3dPOS Y ? 3dPOS Z ? ;
see testZ
cr testZ
cr .s cr bye
[THEN]
---
Have all a nice day,
humptydumpty
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | comp.lang.forth
csiph-web