Subject: Re: Types (in arrays) From: Erik Naggum <erik@naggum.no> Date: 2000/03/06 Newsgroups: comp.lang.lisp Message-ID: <3161298360200823@naggum.no> * Andrew Cooke <andrew@andrewcooke.free-online.co.uk> | I have a program that needs to store many arrays of words (16 bits). the available types are then (unsigned-byte 16), (signed-byte 16), (mod 65536), (integer 0 65535), (integer -32768 +32767), etc, which all should mean the same thing: 16 bits of allocated data per element of the array. if they don't behave the same, you probably have a broken Common Lisp implementation. | My questions are really: | - How do I know which type specifiers are simple enough for a compiler | to understand the implications (1 clearly wasn't - although I may be | wrong in thinking it is a valid type specifier)? the function upgraded-array-element-type will return the internal type it has deemed most optimal for the array element type you have requested. | - Why does case (3) fail silently? probably because the implementation only checks for types it knows, and consider it risky to comment on stuff it doesn't know about. | - How are types used? There seem to be several different things going | on at once - memory size allocation, testing when new values are stored, | initial value allocation (I get zeroes rather than nill if the type is | numeric, for example). this is a very big question. the simple answer is that the vendor has made a number of decisions that are believed to give optimal performance, both in time and space, given the type information you have provided. now, this is not quite the useless answer it looks like, because it means that each vendor will make "personal" decisions about what constitutes "optimal performance" -- and these decisions will naturally differ quite a bit from person to person. one rule of thumb prevails, however: useful optimizations always reflect the capabilities of the aunderlying hardware, so you have to have a fairly good grasp of how the implementation uses machine resources to make the decisions. I'll leave it at that for now, since this is issue that very quickly becomes suiteable for comp.arch. #:Erik