mark4 changed the topic of #forth to: Forth Programming | do drop >in | logged by clog at http://bit.ly/91toWN backup at http://forthworks.com/forth/irc-logs/ | If you have two (or more) stacks and speak RPN then you're welcome here! | https://github.com/mark4th
<veltas> x64 they are next to each other and grow downwards like regular stack
<mark4> a grows down stack is one that when it overflows and segfauls linux automatically assigns a new page to the stack
<veltas> Oh okay
<mark4> is what i meant, its one of the options you can pass to the mmap syscall
<veltas> I just meant the direction of growth
<mark4> ya
<veltas> Of data
<veltas> Not pages
<mark4> the push direction more accurately
<veltas> Yes
<mark4> in x86 thats always down
<mark4> it is also USUALLY down on 32 bit arms too :)
<mark4> put arm did not have a PUSH opcode really till aarch64
<veltas> I don't think I've seen an arch where it's not down
<mark4> it used movm
<mark4> arm can be either diraction
<veltas> It's convenient because your stack contents is at positive offsets from current stack pointer that way
<mark4> you can create a grows up stack in arm
<veltas> And you can stick it at the end of your available memory in a flat setup
<mark4> yup
<mark4> which is what i do :)
<Zarutian_HTC> veltas: 6502 and variants? Motorola 68K?
<mark4> Zarutian_HTC: does that mean coldfire is grows up too?
<veltas> Zarutian_HTC: I was thinking of 6502 but couldn't remember which way, is it really upwards?
<Zarutian_HTC> that Hitatchi sr04 bot uses.
<Zarutian_HTC> in 6502 iirc, the stack is in page 0x0100 and incr when pushed iirc
<mark4> yes the stack is in page 1
<Zarutian_HTC> and I am not sure but I suspect 6502 never had any stack relative memory addressing mode
<veltas> Zarutian_HTC: I just looked it up and it's not upwards, it grows downwards
<veltas> And apparently S points to next free word rather than last allocated word? Very strange
f-a has left #forth [#forth]
f-a has joined #forth
<mark4> 6502 has push and pop but with indexed x and indexed y you CAN index into the stack
<mark4> but i dont think ive ever seen that doen lol
<mark4> veltas: on arm you can make push grow up or down and make the stack pointer point to the last item pushed or to the next cell to push into
<mark4> ldm and stm
<mark4> not movm which is 68k bs lol
<mark4> ldmfd stifd ldmia stmia i think
<veltas> You have told me this like 3 times now mark4
<mark4> veltas: i didnt state taht you can point to full or to empty tho :)
<veltas> I find features like this really pointless
<mark4> well arm does not really have push or pop it has load and store multiple which you can use to do memory to memory moves really really fast
<veltas> Like on PowerPC the ability to work with either endianness is never used, it's just there so NT can be incompatible with everything else
<mark4> lol
<veltas> And big endian itself is utterly pointless and confusing now
f-a has left #forth [#forth]
<Zarutian_HTC> eh, it is left out of the radhardened versions of PowerPC
<veltas> Good
<Zarutian_HTC> I say little endian is pointless on all levels
<veltas> It's like saying 8-bit bytes is pointless
<Zarutian_HTC> and many sane arch have returned to cell addressing instead of byte addressing
<veltas> Big endian gives me 1-based-indexing vibes
<Zarutian_HTC> have you looked how contorted and big little endian adder with and without lookahead is?
<veltas> If it's an 'adder' and it cares about byte order you're doing it wrong
<Zarutian_HTC> whacha mean? adders in most alus and other places in an cpu core are of the full datapath width of the machine, nowdays 64 bit usually
<veltas> Yes so by the time the data gets there it is as a 'word', not in bytes
<veltas> I can read a little endian number from an address as any size, and get the right answer truncated to that read size.
<veltas> Byte indices are in ascending order of shifts/units, so most endian-aware algorithms operating on the raw bytes are cleaner
<veltas> And it's convention now too
<Zarutian_HTC> then why bother with byte addressing? there are byte select instructions/addressing-modes that can select which of eight bytes are used in the calculation
<veltas> So that's all there is to say about it for me, I don't see point in big endian the way I don't see point in 10-bit bytes.
<veltas> Well actually 10-bit bytes aren't worse they're just unconventional
<veltas> I think big endian is actually worse
<veltas> Zarutian_HTC: Why bother? Because e.g. if I want to store an unaligned 24-bit number in a binary format, I can't in general use a single instruction to load that, and would probably be writing C at work anyway so instruction would be irrelevant
<Zarutian_HTC> I know of one exploit (old one) that relied on addresses and ints being little endian
<veltas> There are reasons to want either, but mostly rare concerns. The most common endian-aware code I write is neater with LE
<veltas> For example big endian is better for encoding words in my tokenized forth that are not tokens
<Zarutian_HTC> stack ovetflow by one byte, an ending null byte of the shell string
<veltas> Because I can write the high byte of XT first, and determine if it's in range
<veltas> Or if it's not in range it's the single byte indexing the token vector
<veltas> But it's a specialist usage and machine endianness support here is irrelevant to algorithm
<Zarutian_HTC> that overflow over rode the return address so it started at the 256 byte page of where the calling function was
<veltas> This is not a very strong point against LE in general though
<Zarutian_HTC> it just happened to be a handy gadget that used offsets into the callstack, offsets that pointed into the shell string
<Zarutian_HTC> suffice to say the exploit was rather neat
<Zarutian_HTC> personally I am against little endian in, file formats, network protocols, and device interfacing
<veltas> I wonder if there is a reason
<veltas> The only advantage of big endian I see is making it easier to spot data in a hex dump, because the bytes are in reading order already
<Zarutian_HTC> hours and hours trying to figgure out why a wrong value was being written to a memory address mappend device control register
<Zarutian_HTC> mapped*
<veltas> Yes but the issue there is that there are alternative endianness, you can't blame it on one or the other, only complain that there are two
<veltas> You, at best, can blame it on the less conventional one for trying to stick around, which is big endian
<Zarutian_HTC> oh, no there are not two, there at least three
<Zarutian_HTC> middle endian has it place of honour in the hall of hated abominations
<veltas> "middle endian" just means using both big and little endian I thought
<Zarutian_HTC> the damn compiler thought I was writing an in when in fact the cell-word was an 32 bit split into bitfields
<Zarutian_HTC> an int*
<mark4> doesnt little endian allow you to store a char in a 23487659234659 bit value and you can just printf it ? :)
<veltas> The ZX Spectrum's BASIC stores line numbers as big endian for no apparent reason
<mark4> lol
<mark4> i had a zx81
<mark4> typed a full 16k basic program in by hand and on the final "enter" the ram pack moved and.... it crashed
<mark4> the ram pack plugged in to the back and had legs that lifted the back of the computer up so pushing down too hard unplugged the rm pack lol
* Zarutian_HTC is still looking for that home computer zine that dissasembled Bill Gates MicroSoft BASIC and proceeded to utterly trounch it
<mark4> but i lived in cambridge where clive sinclair lived... never saw him tho
* Zarutian_HTC notes that was in response to Bill Gates (in)famous letter to the editor
* Zarutian_HTC further notes that in next issue after that the zine published much better BASIC implementation
rixard has quit []
<Zarutian_HTC> it was only eclipsed by Bill Gates use of Ctrl-Alt-Del in Microsoft (yes I am aware of the capitalization changed) software
<Zarutian_HTC> you know Windows Logon key combo
<mark4> yea u had to give the vulcan nerve pince to log in lol
<mark4> DUMB
<Zarutian_HTC> it was onstensibly to prevent bluepilling the ui
<mark4> wtf is that lol
<Zarutian_HTC> it is when someone made a full screen application mimicing the logon screen
<mark4> aha
<Zarutian_HTC> the nifty thing that this was before the movie The Matrix had even been shot so the term bluepilling had not yet been coined