Holiday Game
in [ASM]
|
Prev: Win32 non blocking console input?
Next: hugi compo #29
From: NathanCBaker on 5 Dec 2008 14:14 On Dec 5, 4:31 am, Herbert Kleebauer <k...(a)unibwm.de> wrote: > NathanCBa...(a)gmail.com wrote: > > > > The 'mov( 0 ... " is self-commenting. > > > > > > Why should this be better readable than > > > > > > sub.l r0,r0 > > > > > eor.l r0,r0 > > > > > This requires: > > > > > sub.l r0,r0 ; store 0 in r0, this is not declaring a sub-routine. > > > > eor.l r0,r0 ; store 0 in r0, this is not a tail-less donkey. > > > > If it isn't obvious that e.g. "5-5" is the same as "0" then it's > > > better to not do assembly programming. > > > In Algebra, 'func( x ) = func( x ) - func( x )' does not make any > > sense. > > ???? > Why does g(x) = f1(x) - f2(x) doesn't make any sense if function f1 is the > same as dunction f2? > Because, when we substitute a number for the function... 42 = 42 - 42 ....this reduces to... 42 = 0 ....which simply doesn't make any sense. > > But 'func( x ) = 0' does. > > A function f(x) which is constant zero makes the same sense as the > function f(x) = sin(x) - sin (2*pi+x) > But it wouldn't make sense if the function is re-defining "sin()" like so: sin( x ) = sin( x ) - sin( 2*pi + x ) > But what have function to do whith subtracting two integer numbers > "sub.l r0,r0" ? > sub: Subtracts the source from the destination and stores the result in the destination. When you write it as an algebraic sentence using the given argument: destination = destination - source r0 = r0 - r0 > > So, your program avoids calling "library code" by calling the superior > > "Library code" instead?? > > No, it avoids calling program code which I also could write myself as > part of my program. If you want to write a program which is a sequence > of library calls, then there is absolutely no reason to make this calls > in assembly. Tell that to the folks using RosAsm. Tell that to the folks using Masm32. > And with HLA it's even more worse: > > > rand.randomize(); > > player.show(); > > mov( true, edx ); > > If it would be at least > > call rand.randomize > call player.show > move true,edx > That is perfectly acceptable HLA syntax as long as you put ";" at the end of the lines and you previously define "move" using the Compile- Time Language feature. Nathan.
From: robertwessel2 on 5 Dec 2008 17:55 On Dec 5, 8:50 am, Phil Carmody <thefatphil_demun...(a)yahoo.co.uk> wrote: > Yup. The standard doesn't pretend that what it calls a byte > is what the underlying architecture calls a byte. There's > quite a bit of leeway as to how bytes/chars are implemented, > because pointers are kept similarly abstract. Early Alphas > simply didn't have byte addressing, for example, so there's > precedent for consecutive C bytes not having consecutive > machine-addressible addresses (by virtue of them not being > addressible). Fortunately all recent word addressed machines (including more-or- less, the early Alpha, if we want to stretch the definition of word addressed machines a bit) have taken the approach that consecutive words have addresses N units apart where N is the number of bytes in the word. So the actually addressable words (on a 32 bit machine) are 0, 4, 8, 12..., and the byte "addresses" simply fill in the low bits. While they're still no byte addressing, at least the addresses look fairly natural, and are thus easier to manipulate. It was common (but not universal) in the past for word addressed machine to assign sequential words consecutive addresses. IOW, the addresses of the first few words on the machine are 0, 1, 2, 3... That requires mangling your char (and void) pointers so that you can store the byte offset somewhere. Either it's added to the bottom, leaving you with "natural" looking addresses, that you have to shift right before actually using to address storage, or you tuck them in the high end (assuming there's room), where you have to mask them off and then they're hard to use for the shifting of the word itself, or you add them on as an extension, and then you have char and void pointers being longer than other types of pointers. It can certainly be made to work, but is uglier than if the first (and now much more common) scheme is used.
From: Alexei A. Frounze on 5 Dec 2008 18:39 On Dec 6, 1:55 am, "robertwess...(a)yahoo.com" <robertwess...(a)yahoo.com> wrote: .... > It was common (but not universal) in the past for word addressed > machine to assign sequential words consecutive addresses. IOW, the > addresses of the first few words on the machine are 0, 1, 2, 3... > That requires mangling your char (and void) pointers so that you can > store the byte offset somewhere. Either it's added to the bottom, > leaving you with "natural" looking addresses, that you have to shift > right before actually using to address storage, or you tuck them in > the high end (assuming there's room), where you have to mask them off > and then they're hard to use for the shifting of the word itself, or > you add them on as an extension, and then you have char and void > pointers being longer than other types of pointers. It can certainly > be made to work, but is uglier than if the first (and now much more > common) scheme is used. Or one could implement C in such a way that chars and ints are of the machine word size (>= 16 bits). That way the pointers to int and char don't have to be of different size. Example: the compiler for TI's TMS320C54xx series. Alex
From: NathanCBaker on 5 Dec 2008 19:00 On Dec 5, 6:39 pm, "Alexei A. Frounze" <alexfrun...(a)gmail.com> wrote: > > Or one could implement C in such a way that chars and ints are of the > machine word size (>= 16 bits). That way the pointers to int and char > don't have to be of different size. Example: the compiler for TI's > TMS320C54xx series. > Do you happen to know if the booleans were implemented as packed or unpacked? Nathan.
From: robertwessel2 on 5 Dec 2008 19:13
On Dec 5, 5:39 pm, "Alexei A. Frounze" <alexfrun...(a)gmail.com> wrote: > On Dec 6, 1:55 am, "robertwess...(a)yahoo.com" <robertwess...(a)yahoo.com> > wrote: > ... > > > It was common (but not universal) in the past for word addressed > > machine to assign sequential words consecutive addresses. IOW, the > > addresses of the first few words on the machine are 0, 1, 2, 3... > > That requires mangling your char (and void) pointers so that you can > > store the byte offset somewhere. Either it's added to the bottom, > > leaving you with "natural" looking addresses, that you have to shift > > right before actually using to address storage, or you tuck them in > > the high end (assuming there's room), where you have to mask them off > > and then they're hard to use for the shifting of the word itself, or > > you add them on as an extension, and then you have char and void > > pointers being longer than other types of pointers. It can certainly > > be made to work, but is uglier than if the first (and now much more > > common) scheme is used. > > Or one could implement C in such a way that chars and ints are of the > machine word size (>= 16 bits). That way the pointers to int and char > don't have to be of different size. Example: the compiler for TI's > TMS320C54xx series. Of course, but excessively large chars are not pleasant if you have to store a lot of them - or interoperate with a lot of other stuff in the world. So there's strong pressure to implement 8-bit chars, even if it's not particularly efficient or pretty. And the eternal issue that oddly sized chars break a lot of code. It's also arguable that a hosted implementation cannot have sizeof (char) == sizeof(int), because of assumptions in the library (notably you cease being able to assign a unique value to EOF that cannot be returned by the character I/O functions). A freestanding implementation (common, of course, on DSPs), doesn't have those issues. |