| PLEX86 | ||
Where should the type information be 177On Wed, 06 Apr 2005 13:02:53 -0500, Herman Rubin Well, that would seem to add back in (with knobs on!) a lot of the verbiage that you are trying to get rid of, IMO. The alternative is to have explicitly typed operators, which is what forth and some of the ml family (ocaml) use: + is integer addition, +. is floating point addition (or something like that: I don't use either language.) It's possible that this could be finessed with non-ASCII typographical symbols in different weights or fonts, but who wants to be the one who introduced a bug by forgetting to bold-face an operator? :-) There are some processors (eg MMX on Pentia or so) where a register can be operated on as a single value, or as a pair of half-width values, or four quarter-width values or eight eighth-width values (maybe more subdivisions). All of these are available with different mnemonics, in conventional buttembly language, usually through single character suffix combinations. Where should the type information be 178 I cannot do it easily with the present buttemblers. I believe I could do it with buttemblers with notation designed more for users than for the convenience of designers, without... Where should the type information be 180 Herman Rubin I just mean a not-particularly-complex program that looks for and changes your symbology into the functions that you hate to type out in full. Advanced Search... I agree (along with with ml and forth and many buttemblers) that types are how the bags of bits are used, rather that what they're called, although most languages take the variable typing approach that you've mentioned which (at least) avoid the explosion of operator names and symbols that would be needed otherwise. An obvious argument order convention is the strongest (best, IMO) argument for the "algebraic" buttembler syntaxes that are starting to become common. Once you start to add in all of the flags and options commonly available in machine instructions, and give the non-operator instructions function-like syntax, you're not really gaining anything. Consider mnemonic: ldb r0, r1 abs r1, r0 To a putative algebraic: r0 = r1.b r1 = abs(r1) Yes, there's a win in argument order consistency, but I don't see a significant improvement in conciceness, and it becomes a losing proposition as soon as you add conditional end, complicated combinations of operator types and other sharp edges. You also lose consistency and an easy macro syntax. Modern in-line buttembler extensions and processor specific "intrinsics" provide access to most of the odder hardware capabilities from C (or rather, specific compilers that might also do C), so you can get functional syntax with HLL flexibility. Where should the type information be 181 to source By telling him to get somebody else to do the work. He would have long time... -- Andrew
|
||||
Where should the type information be 178 Alt Folklore Computers from Newsgroups The #1 Usenet Provider on the Internet
|
||||