<tp>
presiden, thanks, it is a bit superficial at this point but I really just wanted to show the differences each language takes
<tp>
the different approaches I mean
gravicappa has joined #forth
proteus-guy has joined #forth
mtsd has joined #forth
mtsd_ has joined #forth
mtsd has quit [Ping timeout: 256 seconds]
mtsd has joined #forth
mtsd_ has quit [Ping timeout: 260 seconds]
mtsd has quit [Client Quit]
xek has joined #forth
<veltas>
tp: I prefer your HPRE comment
<veltas>
Because you actually document it's 0xxx, not just "0000", although I get what they're trying to do
<veltas>
This is similar to how I have defined registers, but I prefer separating 'RNAME_MASK' and 'RNAME' to be the unshifted mask and shifted mask
<veltas>
Your forth is actually similar to how some people I know write C
<veltas>
I don't use structs for direct memory maps of registers myself, only for other stuff
<tp>
veltas, for some reason structs seem to be very popular in C when dealing with peripheral register bitfields
<veltas>
Structure for the sake of structure maybe
<tp>
veltas, my naming strategy is that of the cmsis-svd nomenclature, I didnt choose it. My aim was so that readers can go straight from the source to a tech document by searching on the name
<veltas>
Yes that's the way I go too
<veltas>
I don't rename what's in the spec
<tp>
veltas, the peripheral_register_bitfield strategy is one area that is often a source of misunderstanding
<veltas>
And then they go ahead and have separate macros with a consistent naming scheme to refer to the bitfields, distinct from how the struct works, and I wonder why they bothered with how the struct worked in the first place
<tp>
many programmers choose to use just "bitfield" as the full name can be unwieldy, but sadly 'bitfield' names are not unique
<tp>
even register_bitfield names are not unique
<tp>
so in the end I had to use peripheral_register_bitfield names to avoid names clashing
<tp>
veltas, what do you think about Keil needing to create every possible bitfield #define with this strategy ?
<veltas>
Well it's not something I have a strong opinion on, I think that I would do this at work, but only for bitfields I was using
<veltas>
But I might factor it a bit more
<tp>
perhaps as it's a commercial product they feel that they need to value add on top of what CMSIS-SVD offers for free ?
reepca` has joined #forth
reepca has quit [Read error: Connection reset by peer]
<veltas>
If they were predefined and available we use them, often I write code where there isn't such a thing because it's typically implemented per-OS in different drivers
<tp>
I personally think it's a waste of time as 1) they cant account for complex interactions, 2) any engineer doesnt need it
<veltas>
i.e. because I am working outside an OS I have to write a lot of stuff not usually needed
<tp>
veltas, I think youd need a book of API's and have to learn them to even use those #defines ?
<veltas>
We read specs and #define as and when needed
<tp>
veltas, you must be using assembly or C I guess ?
<tp>
veltas, as a Forth user, I don't have and don't need #defines, I don't think I'd want them either
<veltas>
C (assembly typically reserved for initial code to get a C environment ready and where lots of special instructions are needed)
<tp>
they have to be processed outside of C so thats another level of abstraction ?
<veltas>
Well your words are a little like smart defines, as far as I see. Or maybe they're more like proper C 'bitfields' (the ones with : in a struct member) except properly defined
<veltas>
I like your code over the C there
<tp>
veltas, I think I write code much as any hardware guy would do, I try to keep it simple but being able to always trace code to hardware is one of my aims
<tp>
veltas, hmm I like your term 'smar`t defines'!
<veltas>
lol
<veltas>
good
<tp>
minus the ` of course (worn out keyboard)
<veltas>
You could do almost exactly what you did in C++. But you'd be using a *massive* language requiring far more training so it should never be understated how rich forth is
<tp>
this has all evolved for me, my initial 2016 efforts were prehistoric in comparison
<veltas>
If you have a specific ABI and compiler then you could use traditional 'bitfields' in C to do what you have, but people avoid them because they're so badly defined in the standard
<tp>
yes, Ive noticed that bitfields are a source of problems and confusion with hobby embedded C users
<veltas>
Back to writing C and not forth :(
WilhelmV1nWeiner has quit [Quit: leaving]
<tp>
veltas, no I know at least one person has understood my document and can see how I use Forth in embedded and why I have chosen the methods used
<tp>
no = now
WilhelmVonWeiner has joined #forth
<veltas>
C is a great source of confusion with many people who think it's a "really simple obvious language" and it turns out it has skeletons
<tp>
veltas, ah yes monday mor`ning for you
<veltas>
Hmmm :(
<WilhelmVonWeiner>
it's super, super simple
<WilhelmVonWeiner>
until it's not
mtsd has joined #forth
<tp>
veltas, heheh, it looks far from simple when I examine those #defines
<tp>
WilhelmVonWeiner, heh
merkc0 has joined #forth
<tp>
<veltas> Structure for the sake of structure maybe ?? I'm not so sure. It seems that C programmers prefer to deal with CELL's, they like to pack up all the bitfields into a CELL rather than deal with the bitfields on their own ?
<veltas>
You often need to make sure the right accesses are being generated by the compiler, if they're defined as 32/64-bit integers in a struct you can be sure changes will generate the correct sized store/move
<veltas>
In Forth the access size is very explicit everywhere so it's not 'hidden' in something like that
<veltas>
In C it tries to hide it... and then every embedded C programmer has to turf it up somehow
<tp>
veltas, ahh, Ive never thought of it that way
<tp>
veltas, Ive wondered about this for years! thanks :)
<veltas>
merkc0: It depends on implementation, on mine you would need to literally walk through the dictionary headers to find the one that matched (as it is headless). It depends on layout of headers
dys has quit [Ping timeout: 272 seconds]
karswell_ has joined #forth
TCZ has joined #forth
dddddd has joined #forth
dys has joined #forth
rdrop-exit has joined #forth
<rdrop-exit>
c[] hello Forthians
<mtsd>
Hello
<rdrop-exit>
:)
<rdrop-exit>
hi mtsd
<mtsd>
Everything alright?
<rdrop-exit>
all good, yourself?
<mtsd>
Yes, good here too
<mtsd>
clear
<mtsd>
Sorry. Wrong window :)
<rdrop-exit>
np
<rdrop-exit>
dinner's ready, catch you later, stay healthy
rdrop-exit has quit [Quit: Lost terminal]
<veltas>
Are there forths that use a hash instead of storing the word?
<veltas>
Like, very old forth would store 3-4 letters and a count, and the 'count' in this case is a bit like a hash (but not a very good one) and that would actually suffice for most longer words because they happen to be different lengths
<veltas>
But you could keep the name field a fixed size by storing a hash (and maybe an initial fixed number of chars)
<veltas>
And that would actually work in many more cases than storing count + fixed length string
karswell_ is now known as karswell
Zarutian_HTC| has joined #forth
Zarutian_HTC has quit [Ping timeout: 256 seconds]
Zarutian_HTC has joined #forth
Zarutian_HTC| has quit [Read error: Connection reset by peer]
mtsd has quit [Quit: mtsd]
TCZ has quit [Quit: Leaving]
jsoft has quit [Ping timeout: 272 seconds]
mtsd has joined #forth
mtsd has quit [Quit: Leaving]
jsoft has joined #forth
mark4 has joined #forth
Zarutian_HTC has quit [Ping timeout: 258 seconds]
<crc>
veltas: I have done that in the past in some of my forths
<veltas>
crc: Any pros/cons?
mark4 has quit [Remote host closed the connection]
<crc>
not really. the lookups can be faster, since calculating a hash is generally faster than comparing strings byte by byte
<veltas>
Does it save much space or not really?
<veltas>
I guess it depends on your average word size
<crc>
I keep the full name around anyway, so not really for me. It'd save space if discarding the full names
<crc>
on a unix host, my system uses 5,990 locations for names. This could be reduce to 497 if I discarded the full names.
karswell has quit [Remote host closed the connection]
<crc>
a retro/embedded would likely not keep headers on the target, and if it did, would probably just store a hashed version to save space
karswell_ has joined #forth
<crc>
(fwiw, my average word names are 8 characters, with the longest being 23)
Zarutian_HTC has joined #forth
dys has quit [Ping timeout: 246 seconds]
naraic_ has left #forth [#forth]
TCZ has joined #forth
mark4 has joined #forth
xek has quit [Ping timeout: 256 seconds]
<veltas>
crc: Are your names stored with a whole cell per character in the name?
<veltas>
Or is it optimised?
<veltas>
Because I seem to remember you have big characters in retro
<mark4>
why would you store a whole char in a cell?
<veltas>
Just makes the language more consistent and simpler I'm assuming
<veltas>
And adds possibility of easy UTF-32 support, easier than you'd get elsewhere, although not sure if that's supported
<veltas>
Would make the machine code shorter as well I think ??? Can't remember but I have it in my head byte operations produce longer instructions on x86, should check though really
TCZ has quit [Quit: Leaving]
gravicappa has quit [Ping timeout: 256 seconds]
gravicappa has joined #forth
<mark4>
aha
<mark4>
i did not even know there was such a thing as utf-32 lol
<nmz>
a bit overkill considering there aren't even symbols for some things in utf16
<crc>
veltas: yes, one cell per character
<crc>
mark4: my current misc emulation has only word-level addressing
<mark4>
aha
<crc>
so either 32-bit or 64-bit word sizes, depending on how the system is built