<tp>
in this case it knows because bit 22 is read-only, the appropriate action is to test it
<tp>
these are just templates btw, they are pasted and modified if needed
<tp>
it also appends the "?" to the definition name
<tp>
in the following case it does the same, but it's not known if the bit is r/w,r/o,or r/w
<tp>
\ RTC_ISR () Reset:0x00000007
<tp>
: RTC_ISR_ALRAWF? ( -- 1|0 ) 0 bit RTC_ISR bit@ ; \ RTC_ISR_ALRAWF, Alarm A write flag
<tp>
so it determines that the bit is r/o because of the word "flag" in the description field
<crc>
nice
* crc
still dislikes xml though :)
<tp>
crc, everyone does but Ive learned that it's very capable, even xslt-1
<tp>
crc, I do love the embedded templates I can make with it tho
<Zarutian_HTC>
tp: h'lo
<tabemann>
back
tabemann has quit [Remote host closed the connection]
tabemann has joined #forth
rdrop-exit has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<rdrop-exit>
good morning Forthists c[]
<tp>
rdrop-exit, morning Zen Forth Guru!
<rdrop-exit>
hi Forth master Tech (tm)!
<tabemann>
hey guys
<tp>
rdrop-exit, had your coffee yet ?
<tp>
hey tabemann
<rdrop-exit>
hi tabemann
<rdrop-exit>
here it is: c[]
<tp>
rdrop-exit and tabemann mind having a quick look at a very short sample of my latest bitfields output and cast a critical eye ? http://dpaste.com/3KKNGTT
<tp>
I'm now resorting to looking in the 'description field' for transform information
<tp>
these look at a number of factors, the register 'access type' and if unknown the 'description field'. It also makes choices on multi or single bit fields etc
<tp>
where the choice is restricted to one access type, ie 'read-only' it knows the action can only be read related
<tabemann>
where are each parent field defined?
<tp>
tabemann, theyre just a list of memory maps
<tp>
which are all derived address constants
<rdrop-exit>
you always read/modify/write bitfields individually?
<tp>
tabemann, which are uploaded first
<tp>
rdrop-exit, I do
<tabemann>
you know, if this was for zeptoforth
<tp>
rdrop-exit, because in embedded, each bitfield is a 'atom' of hardware configuration
<tabemann>
what I'd do is make read-modify-write words that take lambdas
<tp>
tabemann, programmers do that kind of stuff :)
<rdrop-exit>
not always tp
<tp>
rdrop-exit, please elaborate ?
<tp>
I'm always looking to better under`stand and improve this system, so all criticism and suggestions are gretefully received
<tp>
gratefully even
<rdrop-exit>
some combinations of the different bitfields in a word may be invalid if they work as a group, and therefore should be modified together in a single memory write
<rdrop-exit>
your words return a value and an address, which is not convenient if you want to combine values before writing
<tp>
rdrop-exit, thats perfectly true, and Keil C attempt to do that with their include file, but I observe various fails (I think) with their system
<tp>
rdrop-exit, many words do return a value and an address but only because there are multiple actions possible at that stage
<tp>
rdrop-exit, unless there is only one sensible action choice, in which case the stack comment and word use that
<tp>
such as bit@
<rdrop-exit>
I see where you're doing that, but again are you always doing a memory read for each one of those read-only fields?
Chobbes has joined #forth
<rdrop-exit>
I would normally read the whole register, then isolate the bits
<rdrop-exit>
If a register has 10 read-only bitfields, I don't normally want to do 10 memory reads to get at them
<rdrop-exit>
even more so with writing, I don't want to do 10 individual read/modify/writes to modifiy 10 bitfields
<rdrop-exit>
especially if that might lead to unstable combinations somewhere between the 1st r/m/w and the 10th
<tp>
yes, always doing a read, and it may not be apparent ? but 905% of this stuff all occurs at the application boot up stage
<tabemann>
what I'm almost thinking of is something like [: 0 swap set-FOO 1 swap set-BAR ;] modify-FOOBAR
<tabemann>
where [: ;] is a lambda
<tp>
rdrop-exit, another excellent point re atomic actions
<tp>
tabemann, now I have to go and find out what a lambda is ! ;-)
<rdrop-exit>
tabemann, would that ever be efficient? This is lowest level code we're discussing
<tabemann>
rdrop-exit: lambdas in zeptoforth are very light-weight
<tabemann>
they're not closures
<tabemann>
they're not allocated
<tabemann>
they do not carry state
<tp>
rdrop-exit, thats right, the only 'lower' thing are the memory mapped constants
<tabemann>
all they do is push the address of the lambda onto the stack then jump over it
<tabemann>
lambdas don't even have word headers (they don't exist in the dictionary)
<rdrop-exit>
tabemann, lightweight to me means removing unneeded overhead, not adding it in
<rdrop-exit>
I guess you'd need to compare the machine code that's generated when using your approach, versus the traditional straightforward approach
<rdrop-exit>
^ for tabemann
<tabemann>
they're essentially equivalent to an unconditional branch followed by a CONSTANT when they're instantiated, and when they're executed they're like any other user-defined word
<rdrop-exit>
well, compare the machine code, if it's worse, then why bother
<tp>
tabemann, i will have a go at using your method (when I understand it) and we can compare the file sizes ?
<tabemann>
by that logic we should all be coding in hand-crafted assembly, as Forth code isn't going to approach it in density and speed
<rdrop-exit>
no, that's not the implication
<tp>
tabemann, no that's wrong, we should all be coding in hand coded machine code!
<tp>
assembly is far too wasteful!
<rdrop-exit>
you're saying you would do it in Forth using lambdas, versus doing it in Forth without lambdas. I'm saying I would not bother if all you're doing is adding overhead
dddddd has quit [Ping timeout: 246 seconds]
<tabemann>
there is overhead - 4 instructions worth at instantiation time, 2 instructions worth at execution time
<rdrop-exit>
that's why I wouldn't bother, I really can't see what that overhead is buying me
<rdrop-exit>
I very reticent to add runtime overhead without a very strong reason
<tabemann>
by that logic you shouldn't use ?do +loop
<rdrop-exit>
I rarely use ?do +loop
<tabemann>
in zeptoforth, ?do +loop is far, far more expensive than [: ;]
<rdrop-exit>
I have cheaper looping constructs than ?do +loop for certain situations
<rdrop-exit>
when applicable I use those
<tabemann>
TBH I only use ?do +loop when I really don't care about efficiency
<tabemann>
but the matter is that it constrains one's programming considerably when one is concerned with shaving off every last cycle possible
<tp>
and I'm my case with embedded, speed is my last priority as any MCU is usually a million times faster than I need in the real world
<tabemann>
in most cases in the real world, people are far more liberal in their use of processor time than we Forthers
<tabemann>
like look at the popularity of Java, C#, JavaScript, and Python!
<tp>
eww, must I ?
<tp>
:)
<rdrop-exit>
back
<tabemann>
wb
<tp>
here is a simple example, if I scan a switch in Forth using the shortest, most efficient code, it will be utterly useless to me. In fact to scan a switch, I usually have to stop the MCU for a million clock cycles first, read the switch, stop it for another million clock cycles etc
<tp>
this is just to allow for 'contact bounce'
<rdrop-exit>
tabemann, I think you're looking at it the wrong way, it's not about shaving cycles
<rdrop-exit>
It's about not needlessly adding overhead
<rdrop-exit>
you're adding a new construct to your Forth, that adds runtime overhead, presumably something makes that worthwhile to you
<rdrop-exit>
What I'm not getting is the positive you see with your lambda alternative that makes it worthwhile
<tabemann>
lambdas are about defining executable blocks of code within other words
<rdrop-exit>
especially in this particular case
<rdrop-exit>
tabemann, ok?
<tabemann>
in this case one is defining a self-contained read-modify-write cycle for a register
<tabemann>
in one word
<tabemann>
otherwise you'd have to have a read word and a write word
<tabemann>
naturally the way to do this is to pass an xt to the read-modify-write word that defines the modification desired
<tabemann>
one could do this with defining a new word, and then [']-ing it
<tabemann>
but then you have to pollute the dictionary
<tabemann>
and it looks ugly
<rdrop-exit>
none of that makes any sense to me
<tabemann>
doing it with a lambda is much nicer, and is no more expensive than doing it the other way
<tabemann>
this is coming from a Haskell programmer, and this was precisely the way state is modified in Haskell for a reason
<tabemann>
it makes state modification self-contained
<rdrop-exit>
sorry, but none of that makes any sense to me
<tabemann>
the alternative is to split up reads and writes
<rdrop-exit>
which you need anyway
<rdrop-exit>
unless you're using a cpu instruction that does an atomic r/m/w, you're going to need the factors
<tabemann>
it makes modifying individual fields much simpler, whereas doing it the other way makes it more likely clobber other fields in the register\
<tabemann>
because you have one modify words, and then modify words for each individual field
<tabemann>
for any given register you'd have one read word and one modify word
<rdrop-exit>
you lost me, does anything you said explain why adding lambdas for this vs not ?
jedb has quit [Remote host closed the connection]
<tabemann>
the part where lambdas come into play is that they're nicer here than defining new words for each individual register update desired
jedb has joined #forth
<tp>
note: in cortex-m bit operations have special registers that ensure atomic operations
<tabemann>
lambdas are as cheap or cheaper than defining a new word, considering that each new word has a header, while lambdas are headerless
<tp>
only cell wide writes and reads are not atomic
<rdrop-exit>
is anyone proposing defining new words for each individual update required?
<MrMobius>
hey tp
<tp>
tabemann, your concept does sound interesting
<tp>
MrMobius, hey
<rdrop-exit>
if it's a factor, it should be named
<tabemann>
rdrop-exit, if this were to be implemented, it would require defining new words were lambdas not available
<rdrop-exit>
sorry, what new words?
<rdrop-exit>
In forth, you want to name factors
<rdrop-exit>
if you need to save space, you can always behead them later
<tabemann>
what is your opinion of retro's use of quotations?
<tabemann>
as what I call lambdas and crc calls quotations are the exact same thing
<rdrop-exit>
I haven't looked at retro
<rdrop-exit>
other than snippets posted on this channel
<rdrop-exit>
so lambdas basically add runtime overhead so you can avoid naming a factor?
<rdrop-exit>
seems ass-backwards to me
<rdrop-exit>
need more coffee, brb
<tabemann>
no, they are no more expensive than naming a factor
<rdrop-exit>
in time? space?
<tabemann>
correct
<rdrop-exit>
names can be beaheaded
<rdrop-exit>
as to speed, have you compared?
<rdrop-exit>
and runtime code space?
<rdrop-exit>
I doubt very much lambdas have 0 runtime overhead
<tabemann>
they're one instruction more expensive
<rdrop-exit>
so lambdas basically add runtime overhead so you can avoid naming a factor.
<rdrop-exit>
seems ass-backwards to me
<tabemann>
you're getting hung up over *one* instruction
<tabemann>
and unless factors are beheaded, they're considerably cheaper space-wise
<rdrop-exit>
no I'm hung up on you purposefully adding that overhead, and thinking you've made your Forth better by adding it
<rdrop-exit>
when it seems completely unecessary to have lambdas in the first place
<tabemann>
you seem to have this idea where even the slightest bit of overhead categorically rules something out regardless of whatever benefits it might have
<rdrop-exit>
what benefits?
<rdrop-exit>
I haven't seen the benefits
<tabemann>
being able to define executable blocks from within other code, anonymously
<tabemann>
being able to simply pass code to other words without having to break it out of its relevant context
<rdrop-exit>
if you're passing code to other words you are by definition breaking it out of its original context, it's a factor
<rdrop-exit>
(or a label)
<tabemann>
a key example is words for defining control structures, which by design allow the lambdas passed to them to modify the outside stack, and thus it is useful to define the code passed in immediately before it is executed to make it clear what the stack it sees is
<rdrop-exit>
Sorry, I can't parse that, you can define any control structures you want in your Forth, no lambdas necessary
<rdrop-exit>
Control structure words don't normally deal with xts
<rdrop-exit>
they deal with code addresses
<tabemann>
it's an alternate way of doing data structures
<tabemann>
e.g. look at retro
<rdrop-exit>
I may one day
<rdrop-exit>
but for the moment I'm trying to understand the benefits your lambda example
<rdrop-exit>
benefits of ...
<tabemann>
whoops
<tabemann>
*control structures
<rdrop-exit>
got it
<rdrop-exit>
atm I'm not convinced there are any pluses to using lambdas in low-level code vs not using them
<rdrop-exit>
I'm not even sure there's a real benefit in high level code
<tabemann>
I wouldn't use them if one is writing speed-critical code, where every last cycle matters
<tabemann>
but most code isn't that speed-critical
<tabemann>
where even a single extra instruction is too much
<rdrop-exit>
you keep focusing on little they cost, I'm focusing on why would I want to pay any cost at all if they don't buy me anything
<tabemann>
even in embedded, as tp says, there are more cycles available than one knows what to do with them
<tabemann>
a large part of it is coding style - I come from haskell, were it is the norm to use lambdas liberally
* crc
isn't sure how he'd implement traditional forth control structures in retro efficiently
<rdrop-exit>
maybe they're great for Haskell, but this is Sparta... err... this is Forth
<rdrop-exit>
just because they have clear benefits in Haskell, doesn't necessarily carry over to their usefulness for Forth
<rdrop-exit>
Programmers coming from other languages often bring with them their fetishes from other languages
<rdrop-exit>
But often they're not relevant to Forth
<rdrop-exit>
and can even be counterproductive
<rdrop-exit>
But said programmers are convinced they are absolutely positively necessary because they can't imagine life without them
reepca has quit [Read error: Connection reset by peer]
reepca has joined #forth
<tabemann>
to be honest, I don't use lambdas very much, just because I usually don't find myself having to pass a block of code into something else
<tabemann>
but I like having them available, and find them more natural than named factors in places
<rdrop-exit>
The places where you find them more natural, might be places that need rethinking, as is the case with things like PICK and ROLL.
<crc>
for myself, I can function without lambdas (and did for years), but I personally prefer using them
<rdrop-exit>
I'm careful not to add words to Forth that make it relatively painless to do the wrong thing.
<rdrop-exit>
As Chuck says one change at the bottom can avoid many problems at the top, or something like that, need to dig up the exact quote.
<rdrop-exit>
need c[], brb
<tp>
The evolution of Forth prior to 1978 was completely dominated by Moore himself. As we have seen, Moore was and is a fanatic minimalist, dedicated to the principle of zero-based design in which every feature and every instruction must justify its existence or be ruthlessly scrapped.
<rdrop-exit>
to me it's like, "here's some stinky fish, it only costs you *1* instruction at runtime", hence my reaction of why would I want stinky fish.
<rdrop-exit>
What people don't get about Chuck, is that he's willing to design a new Forth specific to a particular project.
<tabemann>
see, you've already decided it's a stinky fish
<rdrop-exit>
all bloat is stinky to me
<rdrop-exit>
even if it's soooo cheap
<tabemann>
aren't VM-based forths bloat, when one could always compile to native code?
<rdrop-exit>
I know what I'm buying with a VM, and whether in this particular case the tradeoff is worthwhile to me
<rdrop-exit>
both the positives and negatives are clear to me
<tp>
Id be interested to see the kind of bitfield templates that zeptoforth would require with this technique
<tp>
hmm, my neighbour is drunk again and revving the crap out of his highly worked Harley
<rdrop-exit>
:))
<tp>
lol, Im 25 metres away and can feel the vibration thru our common concrete pad!
<tp>
and his engine is HOT, that bike pulls like a x-class locomotive
<tp>
ahh .. the silence is deafening now it's stopped
<rdrop-exit>
While in the case of lambdas it seems more like an affectation
<rdrop-exit>
People coming from languages like Haskell see the world through lambda tainted glasses
<rdrop-exit>
Same with the Object Oriented crowd, they see the world through OO tainted glasses
<tabemann>
tp: the modify words would take the form of : modify-MYREGISTER MYREGISTER @ execute MYREGISTER ! ; and the bitfields would have the form of : set-MYFIELD swap MYSHIFT lshift MYMASK and swap MYMASK not and or ; and : get-MYFIELD MYMASK and MYSHIFT rshift ;
<tp>
tabemann, thanks!
<tabemann>
okay, I'm kinda falling asleep, so I'm gonna hit the sack
<rdrop-exit>
if your Forth does peephole, you can base the shift/ors on the literal mask.