Back
[15:11:09] <joebobjoe> Hi, anyone on?
[15:11:50] <joebobjoe> I have a question about the example of section 57.2 of the AVR ISA man
[15:12:04] <joebobjoe> What does byte3(Table_1<<1) do in assembly?
[15:13:39] <cehteh> just compile and look
[15:14:11] <cehteh> (what does byte3() do? i dont know that)
[15:17:35] <cehteh> ah 3rd byte of a 32 bit val
[15:19:03] <Thrashbarg> "What does it do in assembly?" <-- can you clarify? Do you mean what would the compiled assembler look like, or what would the result of the operation look like (what does it do)
[15:23:24] <joebobjoe> cehteh Thrashbarg: What is byte3(Table_1<<1) doing? Is a label in assembler equal to the word address and not the byte address?
[15:23:39] <joebobjoe> So it has to be shifted over by 1 bit to make a byte address?
[15:24:10] <Thrashbarg> ah it's a C function which returns the third byte of a 32-bit word, as cehteh said
[15:24:27] <Thrashbarg> so the 32-bit word would be shifted once, then the byte returned of that operation
[15:24:29] <cehteh> macro .. prolly the same in assemler
[15:24:31] <Thrashbarg> yup
[15:25:29] <Thrashbarg> also to load from program ROM, you need to use word addressing, not byte addressing
[15:25:36] <Thrashbarg> which means you need to multiply the address by two
[15:25:44] <Thrashbarg> or add it to itself, or shift it left one bit. Same thing
[15:25:52] <cehteh> symbol addresses should be word addresses, not exactly sure but i'd expect that
[15:26:07] <cehteh> havard, text is word addressed
[15:27:05] <cehteh> if done otherwise you run into other problems (16 bit cant adddress 128k)
[15:28:53] <Thrashbarg> okay so I bothered to look up the PDF ... Table_l is an assembler label, as you said....
[15:29:13] <Thrashbarg> joebobjoe: have a look at the details for the LPM instruction, that should explain it
[15:29:29] <joebobjoe> Thrashbarg: you would be multiplying the *word address* of the label by 2 to get the *byte address* right?
[15:29:35] <joebobjoe> Thrashbarg: ok thanks
[15:30:41] <Thrashbarg> the problem is the program memory is 16-bits and the rest of the architecture is 8-bits, so the LPM instruction has to take that into account
[15:30:53] <cehteh> bit odd to do that and i'd expect that it returns a byte ... not a full address
[15:32:36] <Thrashbarg> cehteh: it's to load to the ZL and ZH register pair
[15:32:57] <Thrashbarg> http://www.atmel.com/Images/Atmel-0856-AVR-Instruction-Set-Manual.pdf <-- page 68
[15:33:09] <joebobjoe> cehteh: it does return the byte... but the byte is a byte in the address (the label)
[15:33:47] <Thrashbarg> yeah so the Z register pointer can point at the address, which tells LPM which byte to retrieve
[16:15:22] <joebobjoe> Does the load and clear instruction load first or clear first. For some reason in the manual it looks like it clears first, which doesn't seem useful
[16:16:16] <LeoNerd> I think it's implied to be concurrent
[16:16:29] <LeoNerd> concurrently: load the register from memory, and reset the memory to zero
[16:18:37] <joebobjoe> LeoNerd: so which happens first
[16:18:47] <LeoNerd> Hrm?
[16:18:57] <LeoNerd> "first" isn't a meaningful question about concurrent operations
[16:22:10] <joebobjoe> LeoNerd: but it is meaningful if you're reading from where you're writing to?
[16:22:13] <joebobjoe> right?
[16:22:44] <cehteh> semantically it *moves* the value into a register
[16:22:48] <LeoNerd> Once the instruction has finished, the target register contains the value that the memory cell had before the instruction started, and the memory cell now contains zero
[16:23:03] <LeoNerd> It's not meaningful to talk about what happens *within* the instruction
[16:23:13] <LeoNerd> Only how the state afterwards relates to the state beforehand
[16:23:42] <cehteh> while it would be somewhat interesting at what cycle exactly it clears the content, imagine you reading/clearing a timer register from a running timer
[16:24:02] <cehteh> esp tiny*5 with 64mhz pll/timers
[16:24:11] <joebobjoe> cehteh: what do you mean about the timer?
[16:24:13] <LeoNerd> Well that's the point of it being atomic
[16:24:13] <cehteh> feel free to program a testcase and report :)
[16:24:34] <LeoNerd> It happens at a granularity *smaller* than can be observed by an interrupt, such as a timer
[16:25:05] <LeoNerd> It is, for any practical purpose, "concurrent and instantaneous" because no in-AVR mechanism is able to distinguish it
[16:25:48] <cehteh> thats what i would expect too .. otherwise you have no chance for exact timer access when the timer runs faster than your mpu
[16:26:52] <joebobjoe> ok
[16:34:52] <joebobjoe> Wish I knew more about asynchronous stuff/theory
[16:35:02] <joebobjoe> Can I ask another question? What does the phrase "This instruction features a 100%
[16:35:04] <joebobjoe> space effective constant initialization or constant data fetch"
[16:35:07] <joebobjoe> mean under LPM?
[16:35:34] <joebobjoe> Oh, I see
[16:35:47] <joebobjoe> Because you can byte address the program memory, even though it is usually word addressed
[17:59:52] <joebobjoe> What is PGERS and SPMEN on page 133 of
http://www.atmel.com/images/Atmel-0856-AVR-Instruction-Set-Manual.pdf ?
[17:59:59] <joebobjoe> I tried google to no avail
[18:01:32] <Tom_L> i'm going to say SPMEN is SPM enable
[18:01:36] <Tom_L> SPM*
[18:02:32] <Tom_L> PGERS may have something to do with the page?
[18:02:40] <Tom_L> no idea
[18:02:59] <joebobjoe> oh, page erase
[18:03:02] <Tom_L> yeap
[18:03:06] <Tom_L> beat me to it...
[18:03:14] <joebobjoe> Tom_L: any idea where I could possibly find out what those mean?
[18:03:20] <joebobjoe> Or where they are defined
[18:03:25] <joebobjoe> It is not in the assembler guid
[18:03:27] <joebobjoe> guide*
[18:03:30] <Tom_L> no
[18:03:40] <Lambda_Aurigae> datasheet
[18:03:54] <Tom_L> probably something new for the xmegas or maybe arm?
[18:04:11] <Tom_L> wouldn't be arm since that's an 8bit pdf
[18:04:34] <Lambda_Aurigae> it's in the datasheet for whatever chip supports it I bet.
[18:04:35] <joebobjoe> Lambda_Aurigae: ah thanks. I don't know how I didn't see it :)
[18:04:51] <Lambda_Aurigae> those are just bit definitions.
[18:05:26] <joebobjoe> ah, and spmcrval is what they are naming spm "control" val
[18:05:45] <Tom_L> clear as mud now?
[18:06:12] <Lambda_Aurigae> spmcrval is just a register used as a variable.
[18:06:29] <Tom_L> control reg?
[18:06:54] <joebobjoe> yea
[18:07:28] <Lambda_Aurigae> basically.
[18:07:34] <Lambda_Aurigae> read the comments a few lines above.
[18:07:43] <Tom_L> meh
[18:08:35] <Lambda_Aurigae> nobody reads the comments!
[18:08:36] <Lambda_Aurigae> hehe
[18:08:55] <Tom_L> i would if i needed it
[18:10:27] <joebobjoe> Lambda_Aurigae: I did read the comments... the code just decided to fry my brain with its terrible spacing
[18:10:59] <Lambda_Aurigae> yeah..someone needs to add some spaces in there.
[18:11:53] <joebobjoe> Lambda_Aurigae: I've been reading the manual all day and found numerous mistakes and poor grammar
[18:12:06] <joebobjoe> It is not like ARM's manual
[18:12:37] <Lambda_Aurigae> never read an ARM manual.
[18:12:45] <Lambda_Aurigae> flipped through one once but didn't get into it.
[18:13:13] <Lambda_Aurigae> I like my 8 bit chips for the most part
[18:13:35] <Lambda_Aurigae> with the exception of the pic32 chips which have captured my interest for the last year or so.
[18:13:52] <Lambda_Aurigae> but dang are those datasheets huge!
[18:15:01] <joebobjoe> Lambda_Aurigae: ARM has 8 bit cores
[18:15:24] <Lambda_Aurigae> did not know that...thought they were 16, 32, and 64.
[18:15:34] <joebobjoe> Lambda_Aurigae: oh you're right it is 16
[18:15:40] <joebobjoe> Is 16 closer to 32 than 8?
[18:15:53] <Lambda_Aurigae> yeah.
[18:19:23] <Lambda_Aurigae> AVR caught my attention many years ago when I looked at the assembly language and started having flashbacks to my mostest flavorite cpu of all times,,,the 6502.
[18:32:15] <joebobjoe> Lambda_Aurigae: you're old
[18:32:23] <Lambda_Aurigae> thank you.
[18:32:25] <joebobjoe> I wonder how much longer AVR is going to be around
[18:32:31] <Lambda_Aurigae> my first computer was a commodore vic-20
[18:32:39] <Lambda_Aurigae> my second was a z80 based s-100 bus system
[18:32:54] <joebobjoe> Lambda_Aurigae: that first one is just a keyboard
[18:32:58] <Lambda_Aurigae> my third was a 4-bit computer I built from scratch with wire wrap and 74xx series chip.
[18:33:26] <joebobjoe> Lambda_Aurigae: when you get even older you need to write this stuff down so the younger generation like me can be enlightened
[18:33:27] <Lambda_Aurigae> vic-20 was a fully functioning computer with 5K of ram and 32K of rom!
[18:33:48] <joebobjoe> Lambda_Aurigae: well it has more than my AVR
[18:34:07] <Lambda_Aurigae> but your avr runs faster than the 6502 in the vic-20
[18:34:18] <Lambda_Aurigae> the vic-20 ran at 1MHz
[18:34:27] <Lambda_Aurigae> approaching,,,0.25 mips I think.
[18:34:43] <Lambda_Aurigae> base avr running at 8MHz can approach 8mips.
[18:35:15] <joebobjoe> Lambda_Aurigae: so it does more per clock cycle too?
[18:35:20] <Lambda_Aurigae> by far.
[18:36:07] <Lambda_Aurigae> hmm..seems the 6502 was faster than I thought...at 0.5 mips per 1mhz
[18:36:09] <joebobjoe> I wonder when that AVR backend for LLVM will be finished
[18:36:29] <Lambda_Aurigae> err... 0.42 mips per mhz
[18:36:34] <Lambda_Aurigae> still.
[18:36:43] <Lambda_Aurigae> considerably slower clock for clock than an avr.
[18:36:57] <joebobjoe> Lambda_Aurigae: have you ever written a compiler?
[18:37:01] <Lambda_Aurigae> but still faster than a pic16 without an inboard pll.
[18:37:07] <Lambda_Aurigae> joebobjoe, yes, twice.
[18:37:17] <joebobjoe> Lambda_Aurigae: what do you think of LLVM
[18:37:22] <Lambda_Aurigae> nothing.
[18:37:29] <joebobjoe> Lambda_Aurigae: that is bad
[18:37:41] <Lambda_Aurigae> no
[18:37:46] <Lambda_Aurigae> just means I don't know enough about it.
[18:38:02] <Lambda_Aurigae> and I wrote compilers before I ever heard of an x86 processor.
[18:38:08] <Lambda_Aurigae> much less an avr
[18:38:10] <salad> or care, lol
[18:38:10] <joebobjoe> Lambda_Aurigae: how difficult was it to write a compiler? and how much would you say you learned from doing it?
[18:38:29] <Lambda_Aurigae> well,,my first compiler was written in basic
[18:38:44] <Lambda_Aurigae> to compile vic-20 basic programs into assembly,,,using the built in rom basic functions.
[18:39:01] <Lambda_Aurigae> then I compiled the basic compiler with the basic compiler
[18:39:05] <Lambda_Aurigae> and it worked, for the most part.
[18:39:10] <joebobjoe> Lambda_Aurigae: a self hosting compiler?
[18:39:11] <Lambda_Aurigae> I learned a lot.
[18:39:42] <Lambda_Aurigae> my compiled version ran about 20% faster than the fully interpreted version because I used a lot of the built in rom basic functions.
[18:40:04] <joebobjoe> Lambda_Aurigae: nice
[18:40:08] <Lambda_Aurigae> it was also about 1/5 the size in ram.
[18:40:14] <joebobjoe> Lambda_Aurigae: I wish I could make a project that improved on somethign else
[18:40:30] <Lambda_Aurigae> this was done in,,,,1986
[18:40:38] <joebobjoe> Lambda_Aurigae: BEFORE THE INTERNET?
[18:41:03] <Lambda_Aurigae> well, before the internet hit the public, yeah...when it was called arpanet...and I was a senior in highschool.
[18:41:28] <salad> systems were a lot simpler then in a lot of ways
[18:41:32] <Lambda_Aurigae> yup.
[18:41:45] <Lambda_Aurigae> hell, an AVR is more complex than that whole vic-20 computer system really.
[18:41:47] <salad> putting things together based on datasheets and instruction lists were a bit more manageable for a single person
[18:42:00] <Lambda_Aurigae> salad, still doable...I do it all the time.
[18:42:12] <Lambda_Aurigae> but, I used to write assembly by hand on graph paper back then too.
[18:42:20] <salad> for embedded it is yes
[18:43:02] <Lambda_Aurigae> salad, I've written programs for x86 PC computers many times....a few that didn't even rely on any OS.
[18:43:15] <joebobjoe> I think I want to try to make a compiler for AVR, since I have one. It would be neat to see a result running on an actually machine
[18:43:52] <Lambda_Aurigae> joebobjoe, AVR is a rather complex processor. What language are you going to compile?
[18:44:07] <joebobjoe> Lambda_Aurigae: idk, maybe a lisp?
[18:44:07] <Lambda_Aurigae> C, FORTRAN, PASCAL? or make one up?
[18:44:09] <salad> Lambda_Aurigae: yep. that'd be outside the realms of what most can do though. there's a lot of documentation to go through for that.
[18:44:39] <Lambda_Aurigae> salad, always is..that's why I read on the order of 200 pages of tech manuals, datasheets, and the like every day.
[18:45:26] <Lambda_Aurigae> joebobjoe, the first thing you have to learn when writing a compiler is the language you want to compile...you need to know it inside out, upside down, frontwards, backwards, and several directions slantwise.
[18:46:05] <Lambda_Aurigae> looking back, I did it the hard way.
[18:46:23] <twnqx> Lambda_Aurigae: i'd say it's not much more complicated than a c64 though
[18:46:25] <Lambda_Aurigae> if I was going to do it today, I would built upon a set of finite state machines.
[18:46:27] <twnqx> just... a bit faster
[18:46:42] <twnqx> also, no VIC :P
[18:46:46] <joebobjoe> Lambda_Aurigae: one thing I wonder is how on earth you deal with all the "side-effects" that occur within the machine, like interrupts, timers, etc.
[18:47:00] <Lambda_Aurigae> twnqx, no, but you have things like spi, i2c(twi), and on some chips usb..
[18:47:01] <joebobjoe> Lambda_Aurigae: what language would you use to model the FSMs?
[18:47:16] <Lambda_Aurigae> I do state machines in C
[18:47:37] <joebobjoe> Lambda_Aurigae: you mean write the compiler using FSMs in C?
[18:47:38] <Lambda_Aurigae> or assembly for some implementations.
[18:47:44] <Lambda_Aurigae> sure, why not?
[18:48:02] <joebobjoe> Lambda_Aurigae: how did you do it the hard way?
[18:48:13] <Lambda_Aurigae> I've been doing state machines for many years...before I even knew what a state machine was even.
[18:48:55] <Lambda_Aurigae> the hard way is read a line, pick out the command from a list, and parse everything more or less manually.
[18:49:10] <Lambda_Aurigae> ultimately you are doing the same thing
[18:49:31] <Lambda_Aurigae> but with state machines the logic of decoding the line and the command and everything is more,,,elegant.
[18:49:38] <Lambda_Aurigae> rather than brute force.
[18:49:45] <Lambda_Aurigae> hard to explain really.
[18:52:31] <joebobjoe> Why does AVR seem to have so many instructions that do the same thing
[18:53:17] <Lambda_Aurigae> such as?
[18:54:57] <joebobjoe> um
[18:56:52] <joebobjoe> Lambda_Aurigae: BRBS and SBRS + RJMP?
[18:57:00] <joebobjoe> For checking a bit in the SREG
[18:59:59] <Lambda_Aurigae> well..BRBS is only for testing the SREG
[19:00:45] <Lambda_Aurigae> SBRS is used for testing any of the first 32 bytes of ram or REGISTERS
[19:00:52] <Lambda_Aurigae> not the status register.
[19:00:58] <joebobjoe> Lambda_Aurigae: oh SREG isn't memory mapped?
[19:01:05] <joebobjoe> gah you're right
[19:01:21] <Lambda_Aurigae> for testing totally different thingies there.
[19:01:32] <Lambda_Aurigae> took me a minute jumping back and forth to catch that.
[19:03:26] <joebobjoe> I wonder how you can optimize register saving between compilation units?
[19:03:56] <joebobjoe> As in, how do you know if your procedure should store the values of registers it uses
[19:04:16] <joebobjoe> Maybe all calling procedures don't need them to be saved
[19:04:31] <joebobjoe> But then you'd need some sort of fancy linker, right?
[19:05:32] <twnqx> very, as you'd have to move all register scheduling into the linker, and use a meta language there :P
[19:07:46] <Lambda_Aurigae> I recommend reading how gcc does it...and llvm for that matter.
[19:10:06] <joebobjoe> Lambda_Aurigae: are they actually able to this kind of optimization?
[19:11:04] <Lambda_Aurigae> generally, a set of registers is stored on the stack when calling a function/procedure/whatever....then popped back off and restored where they belong when done.
[19:11:44] <Lambda_Aurigae> I believe there is some optimization done there at times but not sure on the details.
[19:12:27] <Lambda_Aurigae> I know some of this is done with interrupts too....unfortunately I'm not the expert to ask on such.
[19:44:52] <rue_house> anyone know how to get gcc to only preserver the registers it changes?
[19:48:28] <Lambda_Aurigae> not I.
[19:48:36] <Lambda_Aurigae> aaand, bedtime for bonzoids here.
[19:53:08] <cehteh> usually it does, but it has some quirks, if you call a function from there and gcc cant tell what registers that function trashes for example
[19:53:41] <cehteh> maybe -flto helps
[19:53:59] <rue_house> yes, but I think a function call saves registers too
[19:54:38] <cehteh> but by standard gcc has to assume that it complys with the ABI
[19:56:20] <cehteh> for ISR's defining them naked, compile them and then copy paste the generated asm back as inline asm with some optimization helps when you are really in need
[19:57:20] <cehteh> and/or avoid any function calls