1. Re: math.e and misc.e
Robert Craig wrote:
>
> CChris wrote:
> > I'm contemplating a brute force attack against the backend code 
>
> Good Luck.
>
> > It is well written enough, so that all the bit fiddling is inside macros.
> > The
> > number of defined macros and macro calls is finite - the find-in-all-files
> > search
> > option in COntext is a crude and effective xref tool for all #define first,
> > then all the calls that are of interest. Dynamic macro calls would be a
> > problem,
> > but I don't remember there's any.
> >
> > Rob, perhaps do you have this information on some scrap of paper? What is
> > needed
> > is not simply the pattern list as provided, but the exhaustive list of all
> > combinations
> > of tests actually used.
>
> Sorry, I don't have any extra info on paper.
>
> > Once this is done, we can determine exhaustively which bit patterns are used
> > and how, and reorganise them so as to have more room for additional types,
> > one
> > of them would be NIL.
>
> All internal bit patterns are fully documented.
> There are many bit patterns that are not used.
> I use C macros for almost all tests of type etc., but
> some code may take advantage of more subtle relationships
> in the following chart.
> From execute.h ...
>
> unused : 011xxxxx xxxxxxxx xxxxxxxx xxxxxxxx
> unused : 010xxxxx xxxxxxxx xxxxxxxx xxxxxxxx
>
> TOO_BIG: 01000000 00000000 00000000 00000000 (just too big for INT)
>
> +ATOM-INT: 001vvvvv vvvvvvvv vvvvvvvv vvvvvvvv (31-bit integer value)
> +ATOM-INT: 000vvvvv vvvvvvvv vvvvvvvv vvvvvvvv (31-bit integer value)
> -ATOM-INT: 111vvvvv vvvvvvvv vvvvvvvv vvvvvvvv (31-bit integer value)
> -ATOM-INT: 110vvvvv vvvvvvvv vvvvvvvv vvvvvvvv (31-bit integer value)
>
> NO VALUE: 10111111 11111111 11111111 11111111 (undefined object)
>
> ATOM-DBL: 101ppppp pppppppp pppppppp pppppppp (29-bit pointer)
>
> SEQUENCE: 100ppppp pppppppp pppppppp pppppppp (29-bit pointer)
>
> It is tempting to find a way to use the unused bit patterns,
> however, it is extremely important that there be a very
> cheap (one machine instruction) test to determine if a value
> is an integer or not. Also, simple operations on integers (+, - etc.)
> are by far the most common, and are crucial to performance.
>
> You would greatly increase the complexity, and probably seriously harm
> the performance of the entire backend, as well as translated code, if
> you added a new run-time type, that would have to be tested for,
> and dealt with appropriately, everywhere in the backend.
>
> Note that there is already a bit pattern that means "NO VALUE".
> That's how the back-end detects uninitialized variables at run-time.
> However I'm reluctant to make it a visible part of the language.
> It might constrain future optimizations, features etc.
> In most cases the programmer can make up his own special code,
> meaning "error", or "not meaningfully initialized yet",
> or perhaps have several different codes for various kinds of errors.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Fair enough.
It is because what's at stake is so crucial for performance that I think useful
to have a very precise assessment of how the bit patterns are being used.
There is a reasonable chance that the current system cannot be extended while
keeping performance at its current level. Then this assessment will be kept and
used to dismiss any addition about new native types - ASCIZ
(w)string, array of dwords, class-like types, NIL, etc, saving a lot of
discussion based on "perhaps it might hamper performance". It's the "perhaps"
part that hurts. If it appears that some extension could be made without hurting
performance, well... again the assessment will be precisely documented somewhere
for future use.
CChris
