<veltas> But it is a shame to have a situation where I don't know how to use a page correctly because my screen is smaller and stuff gets deleted
<tabemann> back
TCZ has joined #forth
jsoft has joined #forth
<veltas> The "Code It Yourself" manifesto reads like a parody of the Agile manifesto, I wonder if that's intentional
<veltas> crc: Is there a bit in the guide explaining [ and ] ?
<crc> veltas: no, but I will rectify that this weekend
<crc> I think the CSS for the sidebar should be working for 1024 width now
<veltas> crc: It is
<veltas> I am into the "Aim For The Bushes" manifesto
<veltas> Okay nn, thanks for your support today crc hopefully I will play with retro at some point, was just trying to 'learn' the language a bit properly
inkajoo has quit [Ping timeout: 256 seconds]
rdrop-exit has joined #forth
<rdrop-exit> good morning Forthwrights (-_-)zzz c[]
<crc> hi rdrop-exit
<rdrop-exit> hi crc :)
* crc should write a bot to count the nunber of cups of coffee that appear in this channel
<rdrop-exit> :-))
<tp> morning Forth Zen Guru!
<rdrop-exit> hi Forth Master Tech (tm)
<tp> rdrop-exit, how goes Manilla ?
<rdrop-exit> ok, more of the same
<rdrop-exit> c[]
TCZ has quit [Quit: Leaving]
iyzsong has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<rdrop-exit> what's new in the forth world?
<tp> rdrop-exit, I think Ive finished my stack comments, would you mind casting a eye over a short summary of my different auto generated words ?
<rdrop-exit> sure
<rdrop-exit> what is the definition of TSC_CR ?
<tp> I guess I could change "x" to 1|0 where the BIT word is used, as there is only 1 bit involved ?
<tp> TSC_CR is a register so it's definitely is a constant representing it's address
<tp> $40021000 constant RCC \ Reset and clock control
<tp> 184 RCC $0 + constant RCC_CR ( ) \ Clock control register
<tp> 184 is a file line number sorry
<rdrop-exit> thanks
<tp> pleasure
<tp> i see I've been working on this since at least 2017
<tp> adf1d020e1 2017-07-04 12:05:34 Code_Defect Closed some legends fail to be selected in svdcutter.xsl edit
<tp> 1ab7a75e18 2018-05-13 03:13:39 Code_Defect Closed generic register print leaves output on stack edit
<tp> d37ea73d20 2020-04-18 10:37:41 Code_Defect Closed read only has stack comment input byte
<tabemann> hey guys
<rdrop-exit> hi tabemann
<tp> hey tabemann
<rdrop-exit> tp, I don't see anything weird, I'm half-awake though
<tp> rdrop-exit, that bitfields file is 109kb and only has 9/33 peripherals selected, and of those the file you see was just a few items
<tp> rdrop-exit, well thats a start :)
<rdrop-exit> although I would just use constants throughout
<tp> rdrop-exit, when you first looked at them you could have been 1/2 asleep and one eye closed and you'd have seen plenty of issues :)
<tp> rdrop-exit, I totally agree re constants thruout
<tp> rdrop-exit, sadly my efforts have failed so far
<tp> rdrop-exit, Ive had about 3 -4 tries and spent probably a week
<rdrop-exit> I would keep the bitfields separate from the addresses
<tp> rdrop-exit, the problem is that the XML source gives offsets from the main register address, and it's all in decimal
<rdrop-exit> I would do like this
<rdrop-exit> $ 1234 constant RCC_CR
<tp> rdrop-exit, so I have to use XSLT to convert decimal to hex and sometimes the numbers are so large, XSLT reverts to sci notation
<rdrop-exit> 16 bit contant %RCC_CR_HSEON
inkajoo has joined #forth
<tp> rdrop-exit, agree, thats what i initially did
<tp> rdrop-exit, but XSLT processing issues have prevented that
<tp> rdrop-exit, this is a sample from my next version V4 which has been suspended until I fix the problem
<tp> : RCC_CR_HSION %1 0 lshift $40021000 bi? ; \ RCC_CR_HSION; Internal High Speed clock enable
<tp> the stack notation etc is all the old stuff so thats not fixed
<tp> that line is fine as far as the constant goes
<rdrop-exit> what's "bi?"
<tp> a old system to remind people to use bit! bis! or bit@
<tp> rdrop-exit, this one shows my problem
<tp> \ NVIC_IPR8 (read-write)
<tp> : NVIC_IPR8_IPR_N0 ( %XXXXXXXX -- ) 0 lshift $E000E424.76837158203125e-07 bi? ;
<tp> there are around 20 of these scattered throuout my output
<tp> making V4 unusable for neo
<tp> now
<rdrop-exit> ok, the XSLT problem is besides the point
<tp> ?
<tp> it prevents me producing "$ 1234 constant RCC_CR"
<rdrop-exit> what does it produce instead?
dave0 has quit [Quit: dave's not here]
<tp> "$E000E424.76837158203125e-07 constant blah" only in some cases
<rdrop-exit> let me rephrase that, what is your definition of RCC_CR at the moment?
<tp> my mcu doesnt understand sci notation
<rdrop-exit> do you have a working definition of RCC_CR ?
<tp> RCC $0 + constant RCC_CR ( )
<MrMobius> what the heck is that
<tp> thats the working definition of RCC_CR
<rdrop-exit> what's you definition of RCC ?
<tp> $40021000 constant RCC
<rdrop-exit> so the definition of RCC_CR would be
<rdrop-exit> $40021000 constant RCC_CR
<rdrop-exit> is that correct?
<tp> $40021000 constant RCC_CR
<tp> thats from V4
<tp> correct
<MrMobius> tp, where did the idea to use $ come from? ive only seen it for old 8 bit cpus
<tp> MrMobius, I thought that looking at $$$$ all the time would make me rich
<rdrop-exit> many Forths use $ for hex input, and % for binary input
<rdrop-exit> $ ff
<rdrop-exit> % 11111111
<tp> exactly
<MrMobius> neat
<tp> MrMobius, Id prefer "0x" but Forth has it's own ways
* crc uses an optional 0x prefix for hex
<tp> crc, very nice :)
<rdrop-exit> Many old asseblers used $ and %
<tp> MrMobius, so I must use $ for 0x with Mecrisp-Stellaris and lots of other embedded forths
<rdrop-exit> 0x is more of a C thing
<tp> rdrop-exit, it's also a modern assembler thing
<rdrop-exit> or maybe an Intel vs Motorola thing, I can't remember
<rdrop-exit> Motorola used $
<tp> Arm-none-eabi-as use 0x
<rdrop-exit> tp, lets continue with your example
<tp> sure
<rdrop-exit> $ 40021000 constant RCC_CR
<tp> k
<tp> thats my V4 svd2forth
<rdrop-exit> 16 bit contant %RCC_CR_HSEON
<tp> my latest working version is V3, that has all the fixed stack comments
proteus-guy has quit [Ping timeout: 258 seconds]
proteusguy has quit [Ping timeout: 258 seconds]
<tp> ok
<rdrop-exit> 17 bit constant %RCC_CR_HSERDY
<rdrop-exit> etc... etc...
<tp> : RCC_CR_HSEON %1 16 lshift $40021000 bi? ;
<tp> V4
<tp> lol, V4 didnt even have many stack comments
<rdrop-exit> that's what I'm saying, I would just define constants for each register address, and constants for each bitfield
<tp> I cant
<tp> due to a XSLT problem
<tp> as all these constants are derived
<rdrop-exit> argh
<rdrop-exit> you have this:
<rdrop-exit> : RCC_CR_HSERDY ( -- x addr ) 17 bit RCC_CR ;
<rdrop-exit> I would instead have this:
<rdrop-exit> 17 bit constant %RCC_CR_HSERDY
<tp> i understand
<tp> I cant however have that due to a XLST problem
<rdrop-exit> that's unrelated to your XSLT/XML issues
<tp> no, it's directly related
<tp> where do you think the constant value comes from ?
<rdrop-exit> your XSLT can't generate this code?
<rdrop-exit> 17 bit constant %RCC_CR_HSERDY
<tp> not consistently
<tp> only in most cases
<tp> and one fail is the whole lot fail
<tp> this is a XSLT fail
<rdrop-exit> which part of this can't it generate?
<rdrop-exit> 17 bit constant %RCC_CR_HSERDY
dddddd has quit [Ping timeout: 250 seconds]
<tp> it generates that particular one fine
<tp> this is a example of a fail
<tp> : NVIC_IPR8_IPR_N0 ( %XXXXXXXX -- ) 0 lshift $E000E424.76837158203125e-07 bi? ;
<tp> see the constant it generated ?
<tp> $E000E424.76837158203125e-07
<rdrop-exit> but we're not talking about that
<rdrop-exit> we're talking about this
<tp> sure we are
<rdrop-exit> 17 bit constant %RCC_CR_HSERDY
<tp> thats the constant
<tp> we arent on the same page
<tp> having it generate RCC_CR_HSERDY ok, and fail with NVIC_IPR8_IPR_N0 is a system wide fail
<tp> there are thousands of constants that must be generated properly
<rdrop-exit> forget about XSLT for a minute
<tp> no
<tp> XSLT is a vital part of this process
<tp> it cant be ignored
<tp> the fact that RCC_CR_HSERDY is generated is irellevent, it's a low hex value and it works
<tp> but some high values dont
<rdrop-exit> step back for a second from your XML related issues, I am talking about how your factoring the code that you're attempting to output
<rdrop-exit> * you're
<tp> oh ok
<tp> it's the same in all cases tho ?
<tp> it adds the base and the offset
<tp> to derive the constant
proteusguy has joined #forth
<rdrop-exit> <an address> constant <a register name>
<tp> yes
<tp> the address is derived
<rdrop-exit> <a bitmask> constant <a bitmask name>
<tp> from a base and a offset
<tp> correct
<rdrop-exit> My equivalent to the code you're generating would be like that, a bunch of register constants, and a bunch of bitmask constants
<tp> sure
<rdrop-exit> notice I'm not generating colon definitions
<tp> ok
<rdrop-exit> it's all constants
<tp> ok
<rdrop-exit> register constants, bitmask constants
<tp> thats no use to me tho
<tp> absolutely no use
<tp> the reason is all the bitfields MUST be words
<rdrop-exit> a constant is a word
iyzsong has quit [Read error: Connection reset by peer]
<tp> ok
<tp> ahhm you want to make every bitmask a constant ?
proteus-guy has joined #forth
<rdrop-exit> that's what I would do
<tp> ok, I admit I had no clue there for a while
<tp> (whats new?)
iyzsong has joined #forth
<tp> now a bitmask is just a particular bit(s) within a register
<rdrop-exit> yes
<tp> so currently in V3 our example is
<tp> : RCC_CR_HSERDY ( -- x addr ) 17 bit RCC_CR ;
<tp> * incedentally, that definition also makes the actual bit easy to find in the doc
<tp> as in it's bit 17 of RCC_CR
<tp> rdrop-exit, so using that definition, how would you make RCC_CR_HSERDY a constant ?
<tp> I'm still not visualising what you mean
<rdrop-exit> <bitmask> constant <name>
<tp> the problem I see is that <bitmask> MUST be associated with RCC_CR it cant be used anywhere else
<tp> you can't have a 'floating' bitmask
<tp> and you cannot do it from memory
<tp> not with up to 17000+ bitmasks
<tp> well maybe YOU can, I can only remember up to 2 things at anyone time :)
<rdrop-exit> that depends on the target, i.e. if some masks are the same across a subset of the registers
<tp> no
<rdrop-exit> yes
<tp> masks are NOT unique at all times, not even across the same register
<tp> unfortunately
<rdrop-exit> that's what I said, it DEPENDS on the target
<tp> ask me how I know this ?
<rdrop-exit> no
<tp> hahah
<rdrop-exit> :))
<tp> thew target is cortex-m
<tp> svd2forth only applies to cortex-m here
<tp> rdrop-exit, interestingly I see this same methodology youre proposing amongst the C programmer people
<rdrop-exit> I don't think it's related to C or not C
<tp> they have no idea that the bitfield names must be associated with each register, and each register with each peripheral or there will be collisions
<tp> no, I dont either, I do think it's a programmer thing amongst those that dont do much embedded
<rdrop-exit> it depends
<tp> yeah it depends on the target
<rdrop-exit> you might have 3 identical peripherals that you access via different registers, but share the same register layout
<tp> I have ben meaning to write a program that examines any cmsis-svd file for collisions
<tp> thats true, but they have different constants
<tp> a good example would be the USARTS
<tp> there may be 6 of them, all the same except for the peripheral memory constant
<tp> but the register and bitfields are the same
<tp> however the timers, and there are about 7 - 12 of them have about 4 variations
<tp> so thats hard to say
<tp> and in a different model, they may have other variations, so this method could become error prone fast
<tp> thats why I do every register separately
<tp> i see where youre going there for once, and it's a great idea, I just cant see it working well due to all the differences
<rdrop-exit> I use that as my starting point, where I go from there depends on the specifics
<rdrop-exit> My starting point is always register constants, bitfield constants
<tp> you have once again given me a lot to think about :)
<rdrop-exit> I have a bunch of words to extract, manipulate, and pack bitfields that I can use by having that starting point
<tp> the main thing to know is that bitfields cannot exit in isolation, they belong to the same register they are defined in withing the cmsis-svd files
<tp> of course we have been thru this before, your needs are quite different to mine. I need to define all 17000+ bitfields automatically
<tp> you will do all yours by hand
<tabemann> back again
<tp> hey tabemann
<rdrop-exit> yes
<rdrop-exit> I always start with their spec
proteus-guy has quit [Ping timeout: 265 seconds]
<rdrop-exit> I use a similar approach for protocols as well
<rdrop-exit> (and their bitfields)
<tp> in the case of cortex-m, cmsis-svd IS the spec
<tp> it's made by the manufacturer of the chip
<rdrop-exit> I prefer real specs :)
<tp> and their tech docs use it to make the tech docs
<tp> the tech docs use it, theyre one and the same
<rdrop-exit> then I choose the spec that's a real document
<tp> paper you mena ?
<tp> mean
<tp> as in a book ?
<rdrop-exit> I mean the one that's designed for reading with my eyes
<tp> because the PDF specs are sourced from the cmsis-svd
<rdrop-exit> :)
<rdrop-exit> brb
<tp> no problemo, and thanks for the suggestions :)
proteus-guy has joined #forth
<rdrop-exit> back c[]
<tp> off to get some lunch :)
<tp> bbl
<rdrop-exit> bon appetit! :)
merkc0 has joined #forth
gravicappa has joined #forth
proteus-guy has quit [Ping timeout: 260 seconds]
rdrop-exit has quit [Quit: Lost terminal]
proteus-guy has joined #forth
tabemann has quit [Remote host closed the connection]
tabemann has joined #forth
merkc0 has quit [Quit: Leaving]
merkc0 has joined #forth
<merkc0> : BOX ( w h -- )
<merkc0> R> 0 DO
<merkc0> ." *"
<merkc0> 2>R
<merkc0> R> 0 ?DO
<merkc0> LOOP CR
<merkc0> LOOP
<merkc0> ;
<merkc0> 2 10 BOX
<merkc0> any Idea why it enters an infinite loop?
<merkc0> oh the inner R> is called repeatedly, that's not correct
<crc> maybe try: : box 0 do dup 0 do ." *" loop cr loop drop ; or : box 2>r r> 0 do r@ 0 do ." *" loop cr loop rdrop ;
<merkc0> thanks, the 1st solution works, the 2nd one with 2>R R> R@ RDROP still infinite loops
<crc> do/loop may be doing something with the return stack, probably with the loop indices
<merkc0> yes
* crc can't test this currently as the only forth on my current system (an ipad) isn't a standard system
_whitelogger has joined #forth
guan has quit [*.net *.split]
jimt[m] has quit [*.net *.split]
tp has quit [*.net *.split]
APic has quit [*.net *.split]
guan has joined #forth
APic has joined #forth
jimt[m] has joined #forth
tp has joined #forth
rdrop-exit has joined #forth
merkc1 has joined #forth
inkajoo has quit [Ping timeout: 265 seconds]
merkc0 has quit [Ping timeout: 258 seconds]
merkc1 has quit [Ping timeout: 256 seconds]
xek has joined #forth
<veltas> Oh right c[] is a cup of coffee
<veltas> That makes sense now
<veltas> tp: "sometimes the numbers are so large, XSLT reverts to sci notation"
<veltas> That is what I will focus on, use something else :)
<veltas> Has anyone considered stack comments make more sense phantoming where the parameters would be in usage or as equivalent demo code?
<veltas> Like why not : ( w h ) BOX
<veltas> If you called BOX by hand you'd write the w and h there in front
<veltas> Well because : doesn't care about comments
<veltas> But another example, in code sometimes people write out what's happening on stack in different ways
<veltas> But what I do atm is put comments with what's on the stack occasionally in front of the code that uses it
<veltas> and that always seems to give me shorter comments
<veltas> Like this code: : AT-XY ( x y -- ) ( y ) 0 23 CLAMP T-ROW C! ( x ) 0 63 CLAMP T-COL C! ;
<veltas> You could do ( w h ) : BOX
<tp> veltas, whay do you want shorter comments ?
<veltas> And ( n1 n2 ) : + ( n )
<veltas> tp: If they make as much sense, they're easier to read
<veltas> shorter everything is usually easier to read if it still makes sense
<tp> true
<tp> most of my comments are technical, very hard to shorten
<rdrop-exit> c[] back
<tp> : RCC_CIR_CSSC ( -- x addr ) 23 bit RCC_CIR ; \ RCC_CIR_CSSC, Clock security system interrupt clear
<tp> veltas, thats a typical example
<veltas> I'm talking about stack comments right now
<tp> ok
<rdrop-exit> what about them?
<veltas> But if we're talking about your code let's talk XSLT
<tp> sure
<tp> XSLT is everyones favorite Forth I know ;-)
<tp> people might sue us for being off topic
<tp> veltas, but we can discuss it all we like on my embedded ch #mecrisp
<veltas> But I need to sue you for being off topic
<veltas> That's how the courts work these days, instead of having reasonable rules about what you can be sued for they gave up and now you have to counter-sue over everything
<tp> hey it works for the lawyers!
<veltas> lol tp come on it's not like judges are friends with only lawyers and other judges, therefore having an incentive to make law drag on for everyone else when it's pointless ;-)
<tp> no, couldn't be!
<tp> it's not pointless if you bill by the hour ?
<tp> but back to Forth before everyone puts you on ignore
<tp> they come here for Forth, I'm already ignored enough
<rdrop-exit> veltas, what is your definition of CLAMP ?
<veltas> : CLAMP ROT MIN MAX ;
<veltas> without comments
<rdrop-exit> are your x y signed or unsigned ?
<veltas> ( n1 n2 n3 -- n ) \ clamp n1 between n2 and n3
<veltas> signed
<veltas> Well either really but I treat them as signed because the standard unsigned words tend to be more limited
<rdrop-exit> I see
<veltas> Here it really doesn't matter because the variables being modified are c-variable's
<veltas> And if you were trying to set it to 32768 then your code was doing something wrong anyway probably
<rdrop-exit> couldn't you achieve the same thing with 23 umin ... 63 umin ?
<rdrop-exit> oops
<rdrop-exit> never mind
<rdrop-exit> brain fart
<rdrop-exit> I forgot you use signed coordinates
<rdrop-exit> I always use unsigned coordinates
<rdrop-exit> or linear offsets
dddddd has joined #forth
merkc1 has joined #forth
<veltas> rdrop-exit: No I don't use signed coordinates
<veltas> But if I had -1, 0 seems closer to the correct value than 63
<veltas> Coordinates are between 0 and 63
<rdrop-exit> if you're using unsigned coordinates than -1 is a very large number
<veltas> Yes
<rdrop-exit> so it would make sense to clip it to your highest valid coordinate if you're going to clip it anyway
<veltas> But if you're using simple increments/decrements half the time and get it wrong by one you will get -1, or 65535, either way is *meant* to be something near 0 rather than 63
<veltas> If I want to do it with modular arithmetic I could AND it, but I don't, I want to clamp it.
<veltas> Or e.g. you are doing some bad geometry calculation and you want something off the side of the screen, my method will put it on the correct side of the screen at least
<rdrop-exit> ya, I usually don't bother either way
proteus-guy has quit [Ping timeout: 256 seconds]
tabemann has quit [Quit: Leaving]
tabemann has joined #forth
dave0 has joined #forth
rdrop-exit has quit [Quit: Lost terminal]
TCZ has joined #forth
inkajoo has joined #forth
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` is now known as X-Scale
proteus-guy has joined #forth
TCZ has quit [Quit: Leaving]
dddddd_ has joined #forth
deesix_ has joined #forth
deesix has quit [Ping timeout: 250 seconds]
dddddd has quit [Ping timeout: 264 seconds]
dave0 has quit [Quit: dave's not here]
dddddd_ is now known as dddddd
deesix_ is now known as deesix
C-Keen has joined #forth
inkajoo has quit [Ping timeout: 258 seconds]
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 258 seconds]
X-Scale` is now known as X-Scale
merkc1 has quit [Ping timeout: 258 seconds]
inkajoo has joined #forth
jsoft has quit [Ping timeout: 256 seconds]
dys has quit [Ping timeout: 265 seconds]
cheater has quit [Ping timeout: 240 seconds]
TCZ has joined #forth
cheater has joined #forth
TCZ has quit [Quit: Leaving]
Zarutian_HTC has quit [Ping timeout: 256 seconds]
Zarutian_HTC has joined #forth
Lord_Nightmare has quit [Quit: ZNC - http://znc.in]
Lord_Nightmare has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
dddddd has quit [Ping timeout: 240 seconds]
<veltas> [] <- can of beer
<veltas> Hey guys
* jackdaniel takes can of beer
<jackdaniel> hi
<veltas> It's okay I have plenty more
WickedShell has joined #forth
* jackdaniel takes plenty more cans of beer
TCZ has joined #forth
crab1 has joined #forth
<crab1> hello, folks of #forth
<veltas> jackdaniel: Okay jack might want to slow down there m8
<veltas> crab1: Hello
<crab1> How are ya
<veltas> Good as can be
<veltas> You?
<crab1> I'm alright
<crab1> Any interesting projects or anything going on?
<veltas> I don't think my project is interesting but I will tell you what I am working on
<veltas> It is my first Forth, and it is targetting the ZX Spectrum.
<crab1> ZX?
<veltas> Written in Z80 assembly and my forth's colon def parameter data
<veltas> Yes it's an 80s microcomputer, built by Sinclair
<crab1> ahh that sounds vaguely familiar
<crab1> I've been uninspired as far as computing goes as of late
<crab1> how far into writing the forth are you?
<veltas> Don't know
<veltas> I am running stuff but need to write interpreter yet
<crab1> ah that's good
<veltas> Never get enough time and then when I do I spend most of it on other stuff
<crab1> is it open source?
<veltas> It might be when it's done
<veltas> Might as well be because it's so small that one could easily reverse engineer it
<veltas> Especially a forth hacker who knows Z80
<crab1> gotcha
<veltas> crab1: Yeah thinking about it I will make it totally open
WickedShell has quit [Remote host closed the connection]
xek has quit [Ping timeout: 258 seconds]
dave0 has joined #forth
TCZ has quit [Quit: Leaving]
inkajoo has quit [Quit: Leaving]
TCZ has joined #forth
gravicappa has quit [Ping timeout: 260 seconds]
dddddd has joined #forth
reepca has quit [Ping timeout: 256 seconds]
rdrop-exit has joined #forth
TCZ has quit [Quit: Leaving]
reepca has joined #forth
TCZ has joined #forth