<tabemann>
part of the added complexity to my implementation is that I implement handling of lots of 32-bit instructions
<tp>
ah yes
<tabemann>
and I'm commenting most of that out
<tabemann>
because I'm mostly not using 32-bit instructions
TCZ has joined #forth
TCZ has quit [Quit: Leaving]
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
iyzsong has joined #forth
jsoft has joined #forth
iyzsong has quit [Ping timeout: 246 seconds]
iyzsong has joined #forth
reepca has quit [Read error: Connection reset by peer]
reepca has joined #forth
iyzsong has quit [Ping timeout: 260 seconds]
iyzsong has joined #forth
<tabemann>
tp
<tabemann>
I managed to shrink my disassembler by 150 lines without commenting out any code
<tp>
nice!
<tabemann>
what I did was put all the decoding logic into one place
<tabemann>
and make two tables of opcodes, one 16-bit, one 32-bit
<tabemann>
that the decoding logic would process
<tp>
neat refactor!
<tabemann>
so in addition to the one-time cost of the decode logic, the decoding of a 16-bit word takes up 64 bits - 32 for the pointer to the parser word, 16 bits for the mask, and 16 bits for the opcode
<tabemann>
for 32-bit words it goes up to 96 bits per word
<tabemann>
still much cheaper than the hand-coded logic I had before
<tabemann>
and much less error-prone, because it's all written in one place
<tabemann>
I also hacked in logic for it to automatically look up labels for addresses
<tabemann>
using the dictionary, in reverse
<tp>
hmm
<tp>
what kind of addresses ?
<tp>
you mean hardware ?
<tabemann>
xt's
<tp>
ahh
<tabemann>
so when I have a bl instruction I can see which word it is calling
<tp>
aha, of course, you're disassembling
<tp>
are you disassembling everything or just showing the call to dependent words ?
<tp>
Mecrisp-Stellaris does the latter
<tabemann>
I'm disassembling everything
<tabemann>
showing the calls to dependent words would be kinda useless
<tabemann>
since my forth does inlining
<tp>
are you saying that everything is inlined ?
<tabemann>
not everything
<tabemann>
mostly short words without anything PC-relative inside
<tp>
: ADC_CFGR1_DMAEN ( -- x addr ) 0 bit ADC_CFGR1 ; \ ADC_CFGR1_DMAEN, ADC DMA transfer enable
<tp>
so CMSIS gives you a macro, svd2forth gives you a Word
<tabemann>
you could make that word inlined
<tp>
it would be anyway, Mecrisp-Stellaris has automatic inlining
<tp>
if it can be, it gets inlined
<tp>
in a way, I'm blissfully unaware of quite a few Forth choices as Mecrisp-Stellaris does it for me. Forth purists tend to complain, but Im just a user, I'm happy to have others far more expert with Forth make those choices for me
<tp>
one day, if I ever reach those lofty heights, I can change it
ryke has joined #forth
ryke has quit [Client Quit]
<tabemann>
okay, I'm gonna hit the sack - g'night
<tabemann>
and btw, I've committed what I have of the disassembler code in src/common/forth/disassembler.fs
<tp>
cya
<tp>
cool
<tp>
ill have a look
<tabemann>
thanks
<tabemann>
g'night for real now
nmz has quit [Ping timeout: 272 seconds]
nmz has joined #forth
gravicappa has joined #forth
Zarutian_HTC has quit [Ping timeout: 260 seconds]
Zarutian_HTC has joined #forth
proteus-guy has joined #forth
WickedShell has quit [Remote host closed the connection]
dave0 has joined #forth
merkc0 has joined #forth
proteus-guy has quit [Ping timeout: 240 seconds]
proteus-guy has joined #forth
_whitelogger has joined #forth
reepca` has joined #forth
reepca has quit [Read error: Connection reset by peer]
dddddd has joined #forth
rdrop-exit has joined #forth
<rdrop-exit>
good afternoon Forthologists c[]
<merkc0>
good afternoon
<tp>
g'day mate
<rdrop-exit>
hello :) c[]
<tp>
owsitgoingey ?
<rdrop-exit>
good, relaxing with the wife and the dogs
<tp>
(traditional Australian greeting)
<rdrop-exit>
taking a coffee break
<tp>
thats a change!
<rdrop-exit>
coffee usually triggers a check of #forth
<rdrop-exit>
see what's happening with the other 43 Forthers
<tp>
I've run out of Kaluah coffee lacquer, and they raised the price from $27 to $38 so I won't be having any more until they drop it again
<rdrop-exit>
you have my sympathy
<tp>
I'll just have to be strong!
<tp>
Im currently adding a page to my online doc, a overdue comparison of the methods used by C and Forth to configure embedded peripheral devices
<rdrop-exit>
cool
<tp>
this area is best understood by forthers and least understood by C programmers
<rdrop-exit>
tp, our official embassador to Ceelandia
merkc0 has quit [Ping timeout: 272 seconds]
<rdrop-exit>
teaching the Ceelandians the many advantages of Forthacracy
<tp>
hahaha
<tp>
the Ceelandians are parochial lot, mainly superstitious farmers and labourers, quick to anger when drunk.
<tp>
and dont insult their Ghod least you find yourself beset upon by large oafs in hobnailed boots
diginet2 has quit [Quit: diginet has left the building]
<rdrop-exit>
"Minimize syntax in favor of semantics." -- Chuck Moore
diginet2 has joined #forth
<tp>
What Experts Say About Semantics
<tp>
Jenny Lederer, assistant professor and linguistics advisor in the Department of English Language and Literature at San Francisco State University: "Semantics is the study of meaning in context; it's the investigation of how words, phrases and sentences evoke concepts and ideas in our minds. As we learn language, we attach meanings to words by learning what objects and concepts each word refers to.
<rdrop-exit>
that's fairly broad, in narrower computing terms semantics is about the meaning (i.e. action resulting from a piece of code)
<rdrop-exit>
as opposed to syntax which is about what constitutes a "legal" (well-formed) statement in the language
<rdrop-exit>
Forth is closer to an assembly language, no syntax to speak of, just semantics
<rdrop-exit>
"There is no discontinuaty between creation and use with Forth" -- W.P. Salman et al.
<rdrop-exit>
(adding to my collection of quotes)
<rdrop-exit>
* discontinuity
<rdrop-exit>
This is a problem with some Forths and Forth authors/vendors they try to draw a line between the two
<tp>
rdrop-exit, any cooler up your way atm ?
<rdrop-exit>
I'll check
<tp>
rdrop-exit, we are getting lovely Antarctic wind up here and lower temps
<tp>
not so nice further south or down in Tasmania tho
<rdrop-exit>
yes, it's cloudy and cool today, 32C
<tp>
woo
<tp>
was a max of 22c today here
<tp>
some places in victoria are -2C atm
<tp>
and a lot of snow in our alpine regions
<rdrop-exit>
"What is Forth? ... While most people think of it as a language, it is an operating system and an interpreter to its users, and an interactive compiler and an extensible data structuring tool to its programmers" -- Ronald Zech
<rdrop-exit>
I dislike anything below 21C
<tp>
Im ok down to 19C
<tp>
thats 2 degrees of separation....
<rdrop-exit>
:)
<rdrop-exit>
"Forth also retains some of the main advantages of assembly language,
<rdrop-exit>
including being in complete control of the machine and being able, to a large extent,
<rdrop-exit>
to control one's programming environment appropriately to the problem" -- Ronald Zech
<tp>
I think we should ask CRC to make up a big file of Forth slogans and have his retro bot print one every hour :)
<rdrop-exit>
yes!!!
<tp>
or print one when asked
<tp>
ir just typing "retro?" gets the next slogan
<rdrop-exit>
for when you need a "fix" of Forth thinking
<tp>
or Forth propaganda ;-)
<rdrop-exit>
@-@ obey
<tp>
@-@
<tp>
|
<tp>
~
<rdrop-exit>
:))
dddddd has quit [Ping timeout: 256 seconds]
<veltas>
tabemann: I think the right approach with assembly in forth sometimes might be to actually have words that represent the different opcode and parameter components
<veltas>
And then have some mnemonics halfway between assembly and machine code
<veltas>
This would let you have a much smaller assembler, but might make writing assembly too hard.
<rdrop-exit>
IIRC Tabemann is writing a disassembler atm
<veltas>
I want to try and do this with Z80 when I get to it, see if I can learn to write Z80 assembly like that
<veltas>
Ah right
<veltas>
I think this still applies though
<tp>
veltas, just use C d00d3, you know you wanna!
<veltas>
tp: I don't get it
<rdrop-exit>
Forth is great for writing interactive assemblers
<tp>
veltas, thats because you dont have your secret #forth decoder ring!
* veltas
in blissful ignorance
* tp
leads a mainly blissful life ;-)
<rdrop-exit>
but of course whether its a pleasure or a chore depends on the regularity of the ISA
<tp>
veltas, I'm trying to be sarcastic while writing a page on the differences and similarities of C and Forth in embedded
<veltas>
tp: Okay, I look forward to reading the page if you release it then
<rdrop-exit>
writing an assembler for the entire x86-64 ISA would be a nightmare
<tp>
veltas, I release everything when it's finished
<veltas>
Terry Davis wrote an x86-64 assembler, I wonder how comprehensive it was
<tp>
because these things are so complex, no one really knows ...
<rdrop-exit>
The last x86 assembler I wrote was for 386 (or maybe 486 I can't remember)
<tp>
in fact modern compilers are so complex, no one understands them, so the compilers are treated like Gods by the users
<tp>
simply becaue if humans dont understand things, they turn them into gods
<tp>
the god of thunder, rain, fertility etc
<veltas>
LLVM makes the situation more layered but the individual layers are still these big things few people really understand
<veltas>
GCC is actually a relatively sane compiler as things go
<tp>
and now we have the god of C compilers, it knows all and sees men as lowly things, tapping away their lives writing code and praying the Great God of C will protect them from undefined results etc
<tp>
veltas, so men say ....
<tp>
veltas, someone recently asked 'what percentage of opcodes does Gcc actually use?'
<veltas>
Personally I think that the less bloated alternative to mainstream compilers is to write purpose-built compilers for one language/dialect.
<tp>
veltas, and no one was sure
<veltas>
Why does that matter to you?
<tp>
it doesnt matter to me, but it mattered to the poster
<tp>
turns out that Gcc uses about 20% of the available opcodes
<veltas>
You act like all the opcodes are useful to general programming problems. In fact a lot of the ones that aren't are basically assumed that will only be used through assembly or compiler intrinsics
jsoft has quit [Ping timeout: 272 seconds]
<veltas>
Okay the poster acts like
<tp>
as many are too complex to be reliably used
<veltas>
But still I wonder why people analyse it like this
<veltas>
I bet whoever asked this has never read the Intel manual
<tp>
Ive no idea
<tp>
on the other hand, they may know it intimately
<veltas>
I have read a subset of the x86 manuals and written system-level and application-level assembly in free time and at work and I know that many instructions are pointless to general purpose computing like C output
<veltas>
So this does not surprise me
<veltas>
And this would be the case in a good forth as well
<veltas>
Even just using general-purpose instructions it won't be easy to write an assembly for x86, but probably not magnitudes harder than it was for rdrop-exit to write a 386 assembler
<rdrop-exit>
If I were to write an x86-64 (+extensions) assembler today, I would do it incrementally, add instructions and extensions only as the need arises
<rdrop-exit>
But I can't see it worth the bother
TCZ has joined #forth
<rdrop-exit>
If I need to write a some specialized high performance computing product for x86, I'd be more inclined to look into Intel's combined x86+FPGA offerings
<rdrop-exit>
and focus on the FPGA side
<rdrop-exit>
"Forth is an amalgamation of an operating system, a high level language system,
<veltas>
You wrote |= ~1 to set a bit, that would set all but that bit
<veltas>
Your third C example would be written TIM3->CR1 & 1 or (TIM3->CR1 & 1) != 0
Zarutian_HTC has joined #forth
<Zarutian_HTC>
regarding op code utilization
<Zarutian_HTC>
I read somewhere in an old risc paper or such that one should try to get more than one instruction per ten thousand instructions
<Zarutian_HTC>
per possible opcode
<veltas>
I don't really get these metrics just seems a bit puritan
<Zarutian_HTC>
those metrics is more of a rule of thumb than anything
<veltas>
Why is it a rule of thumb though
TCZ has joined #forth
<Zarutian_HTC>
having an opcode space between 17 to 256 possible makes designing the hardware decoding much easier
<veltas>
tp: I think I should write an example driver for a simple peripheral for you in C sometime, influenced by how people around me at work write them and also my own take on 'good' embedded C
<veltas>
So you know what to compare to when you compare Forth and C, because I don't really see code like you've written outside of stuff that's 20+ years old and was only ever intended as throwaway code anyway
<Zarutian_HTC>
and having a such smaller opcode space makes sure that all of the revelant circuitry is exercised
<veltas>
(I mean you've written as a C example)
<veltas>
Zarutian_HTC: Have you designed a CPU, out of interest?
<Zarutian_HTC>
parts there of, some in electromechanical implementation
<veltas>
I'm not trying to tear you down just wondering, it's something a lot of people used to do. I remember seeing some kid make a CPU in minecraft but it wasn't a novel CPU arch, it was taken from a good book
<veltas>
Zarutian_HTC: What parts, like an ALU?
<veltas>
Op decoding logic or something?
<Zarutian_HTC>
and I have played around with J1 from excamera, and some of the dual stack machinrs from Koopmans book
<Zarutian_HTC>
op decoding logic using rom logic techniques
<Zarutian_HTC>
but also combinatoric logic implementation
<Zarutian_HTC>
I quite like dual stack machines as ALU ops can all be happening concurrently to opcode decode. Only the desired ALU function output needs to be selected
<Zarutian_HTC>
and if main, work andor program memory is dual ported then memory fetch can also be one of the concurrent operations
Lord_Nightmare has joined #forth
gravicappa has quit [Ping timeout: 264 seconds]
WickedShell has joined #forth
TCZ has quit [Quit: Leaving]
gravicappa has joined #forth
jsoft has quit [Ping timeout: 240 seconds]
merkc0 has quit [Ping timeout: 272 seconds]
WickedShell has quit [Remote host closed the connection]
Keshl has quit [Read error: Connection reset by peer]
Keshl has joined #forth
Zarutian_HTC has quit [Ping timeout: 265 seconds]
Zarutian_HTC has joined #forth
TCZ has joined #forth
corn has joined #forth
<corn>
Good afternoon, creatures of Forth
<corn>
If I just want something to play with, is the Blue Pill a good choice? I want something either ARM or RISC just to mess around with
<corn>
s/RISC/RISC-V
<corn>
but RISC-V stuff looks expensive from what I can see
<corn>
I want a piece of silicon that I can throw around and smell and taste
<Zarutian_HTC>
you cant smell silicon but you can probably smell the outgassing of the polycarbon package around the silicon chip
<corn>
yes that and I want to taste it too
<Zarutian_HTC>
but I get what you are getting at
<Zarutian_HTC>
most of the risc-v silicon implementations I have seen so far have been univeristy funded and made at TMSC in low volume batches at older feature sizes
<tp>
veltas, you're right! I've taken that page down. My site is for Forth, people who want to learn C for embedded can do that elsewhere
<veltas>
Fair enough
<tp>
veltas, hahah, you're going to write a 'example driver for a simple peripheral in C' for me ? please don't bother, I have no use for 'drivers', especially in C
<veltas>
Well my def of driver is closer to what CP/M would call a driver
<veltas>
But sure okay
<veltas>
I guess I won't bother since you seem to enjoy complaining about C enough already ;)
<tp>
I use Forth to program complex peripherals, each one is tailor made for the application at hand.
<tp>
veltas, I complain for what I consider excellent reasons, such as incomplete online C examples posted by C users
<veltas>
Well I think that is why I offered what I offered, because it would be complete. But I think I see why that would not solve the problem because the incomplete examples still exist
<veltas>
regardless of what I do
<tp>
veltas, if these incomplete examples were a rarity I wouldn't bother complaining, however they are endemic, perhaps a indication of the unsuitability of C for use as embedded examples ?
<veltas>
Complain about the C community all you want I don't really know or work with 'mainstream' embedded C stuff, as far as I know.
<tp>
veltas, one properly written C example hardly fixes the problem
<tp>
and I don't mean 'perfect and up to date coding' by 'properly'. I mean INCLUDING ALL the essential information, such as memory mapping etc
<veltas>
I could complain about C's inappropriateness too and I do. I think you're a bit too harsh on it, I might be biased because I have 99 problems with the way embedded software engineering is done and C only makes up a comparitively less egregious handful of those things
<veltas>
And I have to write C for work so there is that too
<veltas>
Maybe it's easier for me to believe it's not totally incapable at the thing I am supposed to be doing for money lol
<tp>
veltas, C is ok, I've said before that I like it, I can read it, Ive used it to make money myself, but I think it's a disaster in the embedded space. I think C should stick to PC programs
<tp>
veltas, I think one issue is that C systems programmers naturally feel that if C is good for what they do, then it must also be good for embedded development. I have the opposite opinion
<veltas>
Yeah maybe they do I don't know, I mostly write baremetal software
<tp>
veltas, I'm replacing my ancient "c and Forth examples" page with the new "Keil C and Forth" programming peripherals page, Ive learnt a lot already, and there should be a lot more for you to critique :)
<veltas>
I was just trying to help with that other page because it has a mistake and a bit missing
<veltas>
had*
<tp>
veltas, I think our understanding of 'baremetal' is quite different
<veltas>
Er baremetal as far as software gets
<tp>
veltas, and I tank you for it, that page was a discrace
<tp>
+h
<veltas>
I'm assuming you are not assuming what kind of software I write and this is just a general thing about software on the hierarchy for you?
<tp>
the new page only compares a Forth method for programming embedded peripherals to the way that Keil do it in C
<tp>
a double assumption ?
<tp>
assumption squared ;-)
<tp>
veltas, I have no idea what you write, but regardless, I can tell that you and I have very different understanding of the term 'baremetal'
<veltas>
Okay
<tp>
I see C programmers using "baremetal" all the time, and they have no idea that C doesnt even come close to that level, it's more a mantra I think ... i.e. "C is baremetal"
<veltas>
Is x86 baremetal?
<tp>
I dont know anything about X86, I have ever only done small embedded
<veltas>
All I know is that sometimes in my job I am literally diagnosing specific lines of broken metal on boards so it feels very metallic to me
<tp>
but Im guessing no, because all the hardware on x86 is accessed thru the BIOS ?
<tp>
hehe, looking at broken copper tracks on mobos you mean ?
<veltas>
Sometimes
<veltas>
Single board computers, so not really a 'motherboard'
<tp>
When I wrote my first C program for X86 back in 1998, I used direct hardware access of the parallel port, and when I released that under the GPL I soon received a driver to replace that code from a user who said I shouldnt try and access hardware directly, and his suggestion made sense
<tp>
veltas, aha, I see
<tp>
veltas, thats definitely 'bare metal' in that case
<veltas>
The main piece of software I work on can't use 'drivers' for an OS and controls hardware
<veltas>
It literally runs before the 'BIOS' even starts (UEFI in our case for x86)
<tp>
aha, makes sense
<tp>
sounds like POST related ?
<veltas>
Yes it's like a POST
<veltas>
But more sophisticated
<tp>
I have a Intel mobo with a 4 digit HEX LED display for POST on this PC. I can see it running thru the case. It also has activity leds for each core which makes lock up easy to see.
<tp>
in 1985 when I designed and build a hospital solutions bottle filling controller, I found that my self test code was about the same amount as the actual program code
<tp>
so I've used that 50/50 rule ever since
<veltas>
Cool
<tp>
good self test code can be quite complex
<tp>
complex only in the detail of the tests and control it may perfoem