MAXALIGNED and MAXALIGN

forth

    Sponsored Links

    Next

  • 1. Looking for a Forth Developer (starting 70k)
    Looking for a forth developer. Starting salary 70k. Must have: - 5+ years of experience - Experience with bringing up 8bit MCU based boards - Experience with MCUs and all standard interfaces (SPI, I2C UART) - Experience with SwiftX Cross-Compiler highly desired! Email resume to XXXX@XXXXX.COM Please forward posting to any potential applicants. Thanks!
  • 2. Why Not Prolog in Prolog ?
    Duncan Patton wrote: > Bootstrap/portability. And if you watch when you build Gprolog, I don't think bootstrap or portability prevents Prolog from written in prolog. It is a common sense that Forth language gets its portability mainly via metacompilation. Why not prolog in the same way ? Prolog is not a language inferior to Forth. Writing a metacompiler must be a small cake. I don't think written in C/C++ really gives prolog portability. Eg. SWI-prolog was said to be compiled with Visual C/C++. But I have only BC 4.5 in my PC. Do you really think that SWI-prolog can be bootstrapped from the source codes in my PC ? > you will notice a lot of it _is_ written in prolog.
  • 3. Seeking issues of FORTH DIMENSION
    Hi everybody, I am seeking issues of FORTH DIMENSION mentioning MetaCompilation. Especially Issues from Vol. Nr. 14 by B. Rodriguez. Does anybody have those or knows where to get them? Sorry for reposting. Didn't get any hint about getting what I am searching for at first try. Greetings michaeljgd

MAXALIGNED and MAXALIGN

Postby David N. Williams » Sat, 10 Jul 2010 19:55:54 GMT

The ANS/ISO Forth standard only requires CREATE to ALIGN its
data space, which is not sufficient for floating point data on
some systems.  The standard warns about this in Section A.12.3.5.

AFAIK, there is no portable way to define something like
FCREATE.  Several systems handle that as a quality of
implementation issue, by aligning the CREATE data space to the
maximum that occurs in the system.

IIUC, gforth does that, and it also has MAXALIGNED and MAXALIGN,
which could be used in portable workarounds.  My question is
whether common use for these words is possible.  I.e., are there
systems that define them with meanings that conflict with
gforth?

The gforth MAXALIGN does blank padding to alignment, as do its
FALIGN, SFALIGN, and DFALIGN.  I wouldn't include that as a
requirement for common practice.

Here's an example of what I mean by a portable workaround, for a
structure instance of size /POINT containing floating-point
fields of any type:

   maxalign here /point allot constant mypoint

instead of

   create mypoint /point allot  \ may not be fp aligned

-- David

Re: MAXALIGNED and MAXALIGN

Postby Andrew Haley » Sat, 10 Jul 2010 22:03:55 GMT



Isn't MAXALIGN just  ALIGN FALIGN DFALIGN  ?


That looks like an obsolete restriction to me.  It might be worth
saying in an addendum to the FLOAT wordset that CREATE and ALLOCATE
must align sufficiently for floats, and deleting A.12.3.5.

Andrew.

Re: MAXALIGNED and MAXALIGN

Postby David N. Williams » Sun, 11 Jul 2010 02:01:03 GMT




 >> The ANS/ISO Forth standard only requires CREATE to ALIGN its
 >> data space, which is not sufficient for floating point data on
 >> some systems.  The standard warns about this in Section A.12.3.5.
 >>
 >> AFAIK, there is no portable way to define something like
 >> FCREATE.  Several systems handle that as a quality of
 >> implementation issue, by aligning the CREATE data space to the
 >> maximum that occurs in the system.
 >>
 >> IIUC, gforth does that, and it also has MAXALIGNED and MAXALIGN,
 >> which could be used in portable workarounds.  My question is
 >> whether common use for these words is possible.  I.e., are there
 >> systems that define them with meanings that conflict with
 >> gforth?
 >
 > Isn't MAXALIGN just  ALIGN FALIGN DFALIGN  ?

It's equivalent to that for gforth, but not guaranteed by ANS.
There might be a QFALIGN or equivalent, which need not be the
same as FALIGN.  There's XFALIGN in iForth, which is quad
alignment and actually the same as FALIGN, so the above works
for iForth.

The question is, are the names MAXALIGNED and MAXALIGN spoiled
by some other usage?

 >> [...]
 >> Here's an example of what I mean by a portable workaround, for a
 >> structure instance of size /POINT containing floating-point
 >> fields of any type:
 >>
 >>    maxalign here /point allot constant mypoint
 >>
 >> instead of
 >>
 >>    create mypoint /point allot  \ may not be fp aligned
 >
 > That looks like an obsolete restriction to me.  It might be worth
 > saying in an addendum to the FLOAT wordset that CREATE and ALLOCATE
 > must align sufficiently for floats, and deleting A.12.3.5.

That would make me perfectly happy, with "floats" replaced by
maximum alignment.  :-)

Any other opinions?

-- David

Re: MAXALIGNED and MAXALIGN

Postby Andrew Haley » Sun, 11 Jul 2010 02:28:35 GMT







OK, but it's true for any standard program, since a standard program
can't use nonstandard types.


I don't think it makes a huge amount of sense for the standard to
mandate alignment for types that a standard program can't use.

Andrew.

Re: MAXALIGNED and MAXALIGN

Postby Andrew Haley » Sun, 11 Jul 2010 03:13:14 GMT









C says

"The pointer returned [from malloc()] if the allocation succeeds is
suitably aligned so that it may be assigned to a pointer to any type
of object and then used to access such an object or an array of such
objects in the space allocated (until the space is explicitly
deallocated)."

So, OK, there's a precedent.

I don't understand why anyone would want to use MAXALIGNED, though.
Don't they know what types they're using?  Maybe it's just needed
internally as a factor of CREATE.

I wonder if we should be more worried about systems that want to align
8-byte floats or maybe even vectors of floats.  That might be a {*filter*}
waste of memory.

Andrew.

Re: MAXALIGNED and MAXALIGN

Postby David N. Williams » Sun, 11 Jul 2010 03:49:48 GMT






 >>> [...]
 >>>
 >>> Isn't MAXALIGN just  ALIGN FALIGN DFALIGN  ?
 >>
 >> It's equivalent to that for gforth, but not guaranteed by ANS.
 >> There might be a QFALIGN or equivalent, which need not be the
 >> same as FALIGN.  There's XFALIGN in iForth, which is quad
 >> alignment and actually the same as FALIGN, so the above works
 >> for iForth.
 >
 > OK, but it's true for any standard program, since a standard program
 > can't use nonstandard types.

Good point.  There are currently only three standard types, and
whatever be the alignment of a float, ALIGN FALIGN DFALIGN
produces the maximum.

 >> That would make me perfectly happy, with "floats" replaced by
 >> maximum alignment.  :-)
 >
 > I don't think it makes a huge amount of sense for the standard to
 > mandate alignment for types that a standard program can't use.

The nit I'm picking here is that floats need not have the
largest of the three floating-point alignments.

-- David

Re: MAXALIGNED and MAXALIGN

Postby David N. Williams » Sun, 11 Jul 2010 05:06:46 GMT






 >>> [...]
 >>> That would make me perfectly happy, with "floats" replaced by
 >>> maximum alignment.  :-)
 >>
 >> I don't think it makes a huge amount of sense for the standard to
 >> mandate alignment for types that a standard program can't use.

I agree.

 > C says
 >
 > "The pointer returned [from malloc()] if the allocation succeeds is
 > suitably aligned so that it may be assigned to a pointer to any type
 > of object and then used to access such an object or an array of such
 > objects in the space allocated (until the space is explicitly
 > deallocated)."
 >
 > So, OK, there's a precedent.
 >
 > I don't understand why anyone would want to use MAXALIGNED, though.
 > Don't they know what types they're using?  Maybe it's just needed
 > internally as a factor of CREATE.

 From SEE, gforth doesn't appear use it in CREATE.

I was thinking it's just simpler to follow the practice of
"quality" CREATE implementations, and have one overall alignment
at least for structures with floating-point data.  In any case,
if you have both floats and doubles in a structure, a portable
program doesn't know which has the larger alignment without
doing a test.

 > I wonder if we should be more worried about systems that want to align
 > 8-byte floats or maybe even vectors of floats.  That might be a {*filter*}
 > waste of memory.

Just to be clear, I'm only talking about the overall alignment
of a structure or vector.  Alignments of individual fp elements
within such records would be the natural alignments (meaning the
alignment that doesn't incur a speed penalty).

-- David

Re: MAXALIGNED and MAXALIGN

Postby Coos Haak » Sun, 11 Jul 2010 08:35:08 GMT

Op Fri, 09 Jul 2010 16:06:46 -0400 schreef David N. Williams:







It does, in a factor of it: header,

<snip>


-- 
Coos

CHForth, 16 bit DOS applications
 http://www.**--****.com/ 

Re: MAXALIGNED and MAXALIGN

Postby Coos Haak » Sun, 11 Jul 2010 08:44:19 GMT

Op Sat, 10 Jul 2010 01:35:08 +0200 schreef Coos Haak:

I see it's `align' not `maxaligned'
In the 64 bit version, both are multiples of 8.
In the 32 bit version, the first uses a multiple of 4, the second of 8.

-- 
Coos

CHForth, 16 bit DOS applications
 http://www.**--****.com/ 

Re: MAXALIGNED and MAXALIGN

Postby David N. Williams » Sun, 11 Jul 2010 20:39:48 GMT



Thanks, I somehow thought I'd followed every factor far enough,
but obviously hadn't!


Re: MAXALIGNED and MAXALIGN

Postby Andrew Haley » Mon, 12 Jul 2010 23:05:11 GMT




You may be right.  I'm pretty sure malloc() doesn't always align
sufficiently for large vectors, but the standard doesn't talk about
those anyway.


Not necessarily, but I see what you mean.

Andrew.

Re: MAXALIGNED and MAXALIGN

Postby Albert van der Horst » Mon, 12 Jul 2010 23:10:56 GMT

In article < XXXX@XXXXX.COM >,


<SNIP>

I'm not so sure. I don't think the C standard tries to impose
restrictions on non-standard type, that don't exist as far as
the standard is concerned.


If you have 8-byte floats you probably have memory to waste.

I had a similar problem with TICKS-PER-SECOND. If your
system is over 2 Ghz or so it tends to become negative.
I have a crude solution. It is not supported. If you want to
use TICKS-PER-SECOND on a GHz+ system go 64 bits.

Even Microsoft has abandoned DPMI on their latest Windows.


Groetjes Albert


Re: MAXALIGNED and MAXALIGN

Postby anton » Thu, 19 Aug 2010 09:23:32 GMT

"David N. Williams" < XXXX@XXXXX.COM > writes:



Several levels down, it does.

ceate -> header -> header, -> maxalign -> maxaligned


Doubles have the same alignment as cells.  But yes, there is no
guarantee that float-aligned stuff is cell-aligned, and we could have
systems with 64-bit cells and 32-bit floats, all naturally aligned.


"Natural alignment" usually refers to aligning n-byte
hardware-supported types on n-byte boundaries (for n=2^m).

- anton
-- 
M. Anton Ertl   http://www.**--****.com/ 
comp.lang.forth FAQs:  http://www.**--****.com/ 
     New standard:  http://www.**--****.com/ 
   EuroForth 2010:  http://www.**--****.com/ 

Re: MAXALIGNED and MAXALIGN

Postby Andrew Haley » Thu, 19 Aug 2010 17:32:41 GMT





It is: if your hardware wants 16-byte alignment for SSE and so you
always 16-align everything CREATEd, that's not going to get you good
cache utilization.  In the worst case you end up with four variables
per cache line.


Sure, it's not a disaster, but it's not pretty.  And I'm thinking
about scaling: will there be 64-aligned vectors is future?  You
betcha!

Andrew.

Similar Threads:

1.MAXALIGNED and MAXALIGN

The ANS/ISO Forth standard only requires CREATE to ALIGN its
data space, which is not sufficient for floating point data on
some systems.  The standard warns about this in Section A.12.3.5.

AFAIK, there is no portable way to define something like
FCREATE.  Several systems handle that as a quality of
implementation issue, by aligning the CREATE data space to the
maximum that occurs in the system.

IIUC, gforth does that, and it also has MAXALIGNED and MAXALIGN,
which could be used in portable workarounds.  My question is
whether common use for these words is possible.  I.e., are there
systems that define them with meanings that conflict with
gforth?

The gforth MAXALIGN does blank padding to alignment, as do its
FALIGN, SFALIGN, and DFALIGN.  I wouldn't include that as a
requirement for common practice.

Here's an example of what I mean by a portable workaround, for a
structure instance of size /POINT containing floating-point
fields of any type:

   maxalign here /point allot constant mypoint

instead of

   create mypoint /point allot  \ may not be fp aligned

-- David



Return to forth

 

Who is online

Users browsing this forum: No registered users and 78 guest