sorear changed the topic of #riscv to: RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv | Backup if libera.chat and freenode fall over: irc.oftc.net
iorem has joined #riscv
FluffyMask has quit [Quit: WeeChat 2.9]
iorem76 has joined #riscv
iorem has quit [Ping timeout: 268 seconds]
vagrantc has quit [Ping timeout: 272 seconds]
davidlt has joined #riscv
aquijoule_ has joined #riscv
richbridger has quit [Ping timeout: 264 seconds]
devcpu has quit [Quit: leaving]
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #riscv
iorem76 has quit [Quit: Connection closed]
iorem has joined #riscv
davidlt has quit [Ping timeout: 264 seconds]
Sofia has quit [Remote host closed the connection]
Sofia has joined #riscv
Sos has joined #riscv
vagrantc has joined #riscv
vagrantc has quit [Quit: leaving]
riff_IRC has quit [Quit: PROTO-IRC v0.73a (C) 1988 NetSoft - Built on 11-13-1988 on AT&T System V]
elastic_dog has quit [Ping timeout: 245 seconds]
elastic_dog has joined #riscv
davidlt has joined #riscv
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #riscv
frost has joined #riscv
Sos has quit [Quit: Leaving]
hendursa1 has joined #riscv
davidlt has quit [Ping timeout: 264 seconds]
hendursaga has quit [Ping timeout: 252 seconds]
jeancf has joined #riscv
jeancf has quit [Quit: Konversation terminated!]
jeancf has joined #riscv
smartin has joined #riscv
jellydonut has joined #riscv
Andre_H has joined #riscv
mahmutov has quit [Ping timeout: 244 seconds]
psydroid has quit [Changing host]
psydroid has joined #riscv
Pyfisch has joined #riscv
Pyfisch has quit [Ping timeout: 272 seconds]
shoragan has quit [Ping timeout: 272 seconds]
Andre_H has quit [Remote host closed the connection]
shoragan has joined #riscv
Andre_H has joined #riscv
choozy has joined #riscv
Pyfisch has joined #riscv
choozy has quit [Ping timeout: 244 seconds]
Sos has joined #riscv
Pyfisch has quit [Quit: Connection closed]
TwoNotes has joined #riscv
jeancf has quit [Ping timeout: 245 seconds]
frost has quit [Quit: Connection closed]
aquijoule_ has quit [Ping timeout: 268 seconds]
richbridger has joined #riscv
mahmutov has joined #riscv
devcpu has joined #riscv
<sirn> Is my understanding correct that in HiFive Unmatched if I want to boot without an SD card, I have to flash U-Boot SPL to /dev/mtdblock0 and change MSEL to 1001?
davidlt has joined #riscv
Pyfisch has joined #riscv
FluffyMask has joined #riscv
mifr has quit [Ping timeout: 272 seconds]
mifr has joined #riscv
Raito_Bezarius has quit [Ping timeout: 268 seconds]
Raito_Bezarius has joined #riscv
RAM has joined #riscv
jeancf has joined #riscv
RAM has quit [Quit: Leaving]
<TwoNotes> DO I read the AS documentation correctly that '.long' allocates 32 bits for the value?
<TwoNotes> I am using the riscv64-linux-gnu-as assembler
iorem has quit [Quit: Connection closed]
Pyfisch has quit [Ping timeout: 252 seconds]
theruran has quit [Quit: Connection closed for inactivity]
jeancf has quit [Ping timeout: 268 seconds]
Pyfisch has joined #riscv
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #riscv
<khem> seems bitlength is dependent on arch
riff-IRC has joined #riscv
<dh`> twonotes: yes, it's because gas is a legacy of the 80s
<dh`> use the explicitly sized directives
<TwoNotes> So .hword for 16b, .quad for 64b. .word does seem to generate 32b
<TwoNotes> And I use .balign because it seems consistent
Andre_H has quit [Quit: Leaving.]
Andre_H has joined #riscv
<jrtc27> no, use .2byte/.4byte/.8byte
<jrtc27> it's really inconsistent
<jrtc27> *most* architectures have .word mean 32-bit, but not all IIRC
<jrtc27> (intel and/or sparc I feel are 16-bit...)
Pyfisch has quit [Quit: Pyfisch]
<xentrac> on the plus side at least everyone agrees bytes are 8 bits these days...
<xentrac> TwoNotes: what was the BLISS macro system like?
ats has joined #riscv
ats_ has quit [Ping timeout: 264 seconds]
<dh`> m68k is another where word is 16 bits I think
<dh`> or .word rather
<dh`> xentrac: don't tempt me
<xentrac> dh`: what, to build a computer with 9-bit bytes?
<dh`> I've been intermittently working on a 36-bit word-addressed architecture
<TwoNotes> xentrac The Bliss macro system had both iterative and recursive features.
<TwoNotes> Once somebody write an entire 'Towers of Hanoi' program in the Bliss macro language
<TwoNotes> It was wonderful for doing dya structure layouts
<TwoNotes> data*
<TwoNotes> jrtc27, those .Nbyte terms are not mentioned in the AS manual I have
<dh`> they do exist
<xentrac> dh`: oh, you might be interested in PDP-8/X, although it's 32-bit
<xentrac> TwoNotes: sure, but I mean, was it a string-rewriting kind of thing, or more term-rewriting-esque, and when did macros get expanded?
<xentrac> did it have data-structuring facilities beyond the strings/trees of the macro language itself, like dictionaries/hashtables?
<TwoNotes> Oh, it was not with strings, it was with lexical terms. It happened AFTER lexical scanning but before Syntax analysis
<xentrac> dh`: I think word-addressed architectures are in general significantly simpler at the hardware level
<xentrac> nestable lexical terms or just sequences of tokens?
<TwoNotes> Lexical scan converted chracter streams into 'lexemes'. Syntax analysis converted Lexeme streams into syntax trees.
<dh`> I dunno about that, the memory interface becomes simpler but you end up with more bitslicing instructions
<TwoNotes> Sequence of token
<xentrac> dh`: yeah, you can
<TwoNotes> There was one stepo after Syntax analysis I was also responsible for, called Flow Analysis, which looked for moving merging subsexpressions, and movinf constant expressions out of loops.
<xentrac> TwoNotes: if you invoked a macro with a macro call as an argument, did the inner macro get expanded before expanding the outer macro call? or was it passed in as a lexeme stream which might get output by the outer macro call zero or more times, then expanded each of those times?
<xentrac> the flow analysis part was at the BLISS level, right? rather than the macro-system level
<TwoNotes> You had control over when 'quoting' and 'unquoting' happened. That was the most complex part and the one s people had the most trouble with
<jrtc27> early alpha tried not having byte addressing
<xentrac> (those aren't the only two possible orderings, GPM did a weird kind of mixture hybrid still don't fully understand)
<xentrac> jrtc27: so did the whole line of TI DSPs, and the CDC 6600 and its progeny, and and and and...
<xentrac> oh and obviously the PDP-10
<TwoNotes> xentrac it went Lexical - Macro - Syntax - Flow
<xentrac> okay, that's what I thought
<TwoNotes> There was no 'pre-processor' like C has. It was all internal
<xentrac> right, although modern C compilers often are more tightly integrated with cpp
<xentrac> what was the reduction order? I guess first I should ask if the macros had arguments as such
<TwoNotes> After 'Flow' came a pass called 'Delay' and then was 'CodeGen', and finally a peephole optimizer.
<TwoNotes> I think "Delay" is where Register assignment happened
<xentrac> yeah, makes sense
<TwoNotes> Oh yes, macros had arguments. Very flexible system incorporating somehting like varargs
<xentrac> So there was some kind of quasi-syntax-analysis thing going on to allow nested macro calls to happen inside a macro argument?
<xentrac> Did quoting nest the way it did in GPM, m6, and m4?
<TwoNotes> More complexity than you can imagine
<TwoNotes> You could wrap things in quotes, and then each unquote operation removed one layer
<dh`> well, realistically C preprocessing happens after tokenization
<xentrac> dh`: yeah, but historically anyway the output was a byte stream which then got tokenized a second time ;)
<xentrac> TwoNotes: Heh, clearly you have not witnessed the horrors within my mind
<dh`> the difference between preprocessor-tokens and tokens is mostly whether pp-numbers are valid numbers, plus waffling about include file names
<xentrac> Did implicit unquoting happen on input or output or both?
<TwoNotes> It was so long ago.... We are talking late 70s here
<dh`> and if cpp output -> text -> tokens isn't an identity transform your compiler's borked
<TwoNotes> The language was invented at Carnegie Mellon university
<xentrac> dh`: yeah, also in K&R people would do token pasting with things like #define bar(n) foo/**/n(n, ctx)
<xentrac> TwoNotes: haha, yeah, I know :)
<dh`> yeah but (a) there's a reason that's deprecated and (b) there are some dirty secrets about it, it's not just creating an empty spacer
<xentrac> dh`: also K&R cpp was oblivious to strings (one good reason to use all-caps for your macro names)
<xentrac> it's not just deprecated, it's actually removed. it doesn't work in ANSI C
<xentrac> never has
<dh`> xentrac: I wrote a K&R cpp that's gotten some uptake for various things
<dh`> it's deprecated in the sense that K&R dialect is deprecated
<xentrac> interesting, what kind of things?
vagrantc has joined #riscv
<xentrac> yeah, but that's the same sense that Pascal is deprecated
<xentrac> Kernighan wrote a paper deprecating Pascal
<dh`> well, I wrote it ("tradcpp") for use in pkgsrc but it seems to have migrated about a bit
<xentrac> it's not a deprecated feature of ANSI C like implicit function declarations
<TwoNotes> Some history of Bliss here: https://compilers.iecc.com/comparch/article/87-07-029
<xentrac> sounds pretty useful! I imagine a lot of current retrocomputing efforts use it
<xentrac> TwoNotes: yeah, I read that thread when you linked it the other day
<dh`> true, but it's a deprecated feature of C-in-practice
<TwoNotes> Half of the VMS operating system was written in Bliss, and all the compilers and runtime library. Some analysis was done of bug reports and the 'bugs-per-thousand-lines-of-oce' figure was worse for assembly vs Bliss. I don't know if that says somehting about the language or about the type of people using it
<xentrac> no, it's not a feature of C-in-practice at all
<xentrac> except in retrocomputing exercises
<dh`> you'ld be surprised how much code still contains K&R preprocessor frobs in ifdefs
<xentrac> (I think? maybe current C compilers can enable support for it?)
<dh`> mostly not at this point, which is why tradcpp got written
<TwoNotes> True hell is working in a shop which only allows the lowest-common-demoninator oc C so that the code is maximally portable.
<xentrac> oh, I see
<xentrac> what are the dirty secrets?
<xentrac> TwoNotes: haha
<jrtc27> dh`: void foo(P(void)); :)
<xentrac> TwoNotes: it might not be one or the other. BLISS's lack of goto might have encouraged people to write better code, for example
<TwoNotes> xentrac I think that is true. I have NEVER used goto since then, even in languages that have it. Just learned how to think differently
<jrtc27> uh, or P((void)) even
<xentrac> TwoNotes: so BLISS changed the type of people you were :)
<TwoNotes> for usre. It was one of the first goto-less languages I think. Well, maybe Lisp
<dh`> I can't remember the details, but iirc in order to have an implementation that behaved as expected tradcpp had to be aware that /**/ was a specific construct
<TwoNotes> for sure
<xentrac> TwoNotes: I'm interested in learning more about the macro system
<xentrac> Lisp in practice always had GO
<xentrac> well. I mean Scheme doesn't
<xentrac> but the earlier LISPs did
<TwoNotes> I have no idea of the Bliss manual is still availbel somewhere. I was a proofreader for volume 1. I refused to proof volume 2.
<xentrac> dh`: oh no, so foo/* x */n wouldn't work? :)
<xentrac> haha, why?
<dh`> not sure, and like I said I forget
<dh`> if you really want to know I can try to rake it up
<TwoNotes> They assigned a Tech writer to the project who was NOT a programmer. So I wrote a 30 PAGE review, outlining in great detail all the mistakes, so that management would see how bad it was
<TwoNotes> They answered "Great Job, now would you review Vol2?" My answer was, you missed the point
<TwoNotes> A great story: there was a bug in the register assignment logic that affected the code generated for the CASE statement. It took several days to track down becuase the part of the debugger (also written in Bliss) that procesed the "examine" command happened ot use a CASE staement, which had bad code in it due to the very bug we were chasing down
<TwoNotes> I worked very closely with the Debug project leader on that one. Luckily our cubicles were across the aisle from each other.
<TwoNotes> But one of the development rules was "Always eat your own dog food"
<xentrac> dh`: I'm curious but I don't feel like you owe me any such thing :)
<TwoNotes> So the Bliss compiler was written entirely in Bliss.
<xentrac> TwoNotes: haha oh no
<xentrac> yeah, I had some fun nights like that a couple of months ago
<xentrac> "I thought I fixed this bug! Why doesn't it work?" Well, yes, I fixed it, and I recompiled the stage 2 compiler I was using to compile stage 3 with, but the bug was still in stage 1, so stage 2 still didn't work right
<xentrac> had to recompile the stage 1 compiler as well!
<TwoNotes> On odd-numbered weeks, the VMS core devlopers had to do their work on their very latest own version. On even numbered weeks they were allowed to use the stable version, so they could fix all the bugs they found the porevious week
<xentrac> hahaha
<TwoNotes> This was back in the days where the VAX hardware was a hand-built wire-wrapped thing.
<TwoNotes> When we got the first manufacturing prototypes, things started working better
<TwoNotes> Then they took one to a trade show and on the way back accidently dropped it off a fork lift
<xentrac> :'(
<TwoNotes> This all took place in a building that was constructed BEFORE the US Civil War
<xentrac> right, because Massachusetts
<TwoNotes> The only room with AC was the one with the computers in it. So any excude to have to work in their ws sought
<TwoNotes> *excuse
<xentrac> hahaha
<TwoNotes> FInally they retrofitted the old building with central AC
<xentrac> it's kind of disappointing that our available computing power has increased by eight orders of magnitude without making it easy to write something like VMS
<xentrac> you'd think we could have found a way to use all that extra power to make things a lot more debuggable
<TwoNotes> Integrated environemnts are a whole lot better. Microsoft's "VIsual C#" is a good example
<TwoNotes> But you aren't going to write kernel-mode stuff in C#
<xentrac> Cosmos did
<xentrac> I agree that VC# or Emacs or IDEA is substantially better than the stuff we were doing in the early 01980s, although if you compare it to Turbo Pascal instead of the VMS environment the difference is less staggering
<TwoNotes> Emacs was around then. We used Emacs on the Bliss project.
<xentrac> and there are other developments that I think make a much bigger difference: DTrace, Valgrind, Hypothesis, Docker, Coverity, Grafana
<xentrac> yeah, but Emacs in 02021 can do a lot more than Emacs in 01982
<TwoNotes> But being able to right-click on a name and see its definition is a typical hting I was talking about
<xentrac> yeah, but you could do that in vi in 2.9BSD in 01978
<xentrac> except that you didn't click of course, you used ^]
<TwoNotes> We used emacs on a TOPS-20 system, then cross-compiled it to VAX hardware, then copied the files over to the VMS system
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<TwoNotes> The project was to get the compiler rnning in native mode on the VAX
TMM_ has joined #riscv
<xentrac> But VMS itself you built on VMS, right?
<TwoNotes> Same deal: Start on TOPS-20, then copy
<xentrac> Not at first I mean
<xentrac> but once you were dogfooding in earnest
<TwoNotes> Oh yes, everything ran native after a while
<TwoNotes> Tops-20 is a 36-bit word-addressed system.. VMS is 32-but byte-addressed. There were htings ot chase down :)
<xentrac> haha
<xentrac> I think the most advanced development environment I commonly use is the browser development tools, which let you interactively inspect the DOM while your program is running
<xentrac> and walk you through the rule-based application of CSS to your layout
<xentrac> which, admittedly, is kind of special-purpose; inspecting the layout won't help you debug your register allocator much
<TwoNotes> It was exciting being there in the early days of one of the industry-changing projects. I would peronsally interact with people now considered legends
<xentrac> :)
<TwoNotes> Not to name drop, but Gordon Bell once visited me, in *my* office.
<xentrac> haha
<xentrac> he was *already* a legend tho
<TwoNotes> It was on his advcide, years later, that Ethernet was put in the public domain, rather than being a Xeroc/DEC patent
<xentrac> I think things like OCaml, Z3, Coq, and American Fuzzy Lop (and the litany from earlier: DTrace, Valgrind, Hypothesis, Docker, Coverity, Grafana) are in some sense bigger advances in getting software working than the progression from Emacs on Twenex to modern VC#
<TwoNotes> Once we were short of conference rooms. The secretaries would talk aback and forth aboiuyt what room was available. So one week we had our staff meeting in Ken Olsen's private conference room. I sat in his very old ratty chair.
<xentrac> and I guess the fact that our computers go a million times faster means that we can write significant systems in Python even though it wastes 98% of your CPU
<TwoNotes> That is true
<xentrac> it's definitely easier to get stuff working in Python or JS than in C or Forth (or, I'm guessing, BLISS)
<TwoNotes> In college we had an IBM 370/75 with the amazing clock speed of 200ns! That is 5 MHz. And it filled a room
<TwoNotes> sorry 360/75
<xentrac> have you tried writing a BLISS compiler for RISC-V or some other modern CPU?
<TwoNotes> It might have had 2 MB of memory
<xentrac> maybe with more lowercase
<TwoNotes> gack, no
davidlt has quit [Ping timeout: 244 seconds]
<xentrac> haha, why?
<TwoNotes> One reason we did a lot in upper case (the compiler did not care) was because some of the early line-printers could not print lower case letters and just put blanks in rather than folding to upper
<TwoNotes> So for the ocst of a diode on one bit, they could have fixed that
<xentrac> hahaha
<xentrac> yeah
<xentrac> I think even the VT50 was uppercase only
<xentrac> though I guess that was probably before your time
<TwoNotes> No, I used a VT50, and yes it was UC only
<TwoNotes> Real boat-anchor stuff in those days
<TwoNotes> Designed I think by Tom Stockebrand, who also invented DECtape
mhorne has quit [Ping timeout: 245 seconds]
<TwoNotes> I met him once. A real character
<xentrac> nice
<xentrac> I used DLT in the 01990s
<xentrac> I still think the mechanics of that thing are black magic
<TwoNotes> DLT?
<TwoNotes> IBM was famous for their Rube Goldberg hardware, like the IBM 2321 "Noodle Sucker". https://en.wikipedia.org/wiki/IBM_2321_Data_Cell
<sorear> 400MB random access in 1964 doesn't seem that bad
<geist> oh wow that is an interesting piece of tech, never heard of it
<sorear> "seek" time only a couple times worse than 90s rotating disks
<TwoNotes> I had a summer job in a place that had one. I never had to use it myself
<xentrac> the noodle sucker is pretty interesting
<xentrac> I guess a NAND Flash chip is a modern equivalent
<xentrac> a sector is a noodle
<xentrac> I wonder if things like this noodle sucker partly explain why IBMers stopped saying "disk"
<TwoNotes> They say DASD. Direct Acess Storage Device
<TwoNotes> The goofy thing about the 2321 was how they got the noodles back into their storage slots. By applying a vacuum to the bottom.
<TwoNotes> And the fact that it used hydraulic fluid
<sorear> i'm amazed they were able to get anything involving manipulation of flexible objects to work reliably
<dh`> xentrac: I remember what the issue was, it's not that /**/ is a special case but that you have to strip comments just so to make it work as intended
<xentrac> yeah. but until the 01960s they said "disk" like normal people instead of a made-up acronym nobody else uses
<xentrac> dh`: isn't that always the case with cpp?
<dh`> kind of
<xentrac> I mean in ANSI C you "strip" them by replacing them with whitespace instead of ε
<dh`> but you need multiple remove-comments passes
<xentrac> oh really?
<dh`> yes
<dh`> if you remove the /**/ in a macro body before you do the argument substitutions, it obviously doesn't work
<sorear> rotational disk, solid state disk, noodly disk
<sorear> would call it a block device except I think those were a bit more flexible with formatting
<xentrac> yeah, one of the interesting things about cpp is that that I think it only expands macro invocations on *output* (normal-order reduction) rather than on input (like GPM and I think m6) or both input and output (like m4)
<dh`> also, while macro substitution occurs within quoted strings, comments don't
<dh`> so it is not that you can just ignore strings
<xentrac> sorear: yeah, a magtape is a block device too I think? in the Unix sense
<sorear> not yet familiar with gpm or m6
<dh`> tapes are block devices in unix, yes, even though it's a pretty poor fit
<xentrac> m6 was a Unix near-clone of GPM
<xentrac> except that of course it couldn't use § like GPM did
<sorear> i don't quite understand that
<sorear> wasn't the point of block devices that they could be larger than 64k before lseek was a thing?
<sorear> whereas tapes don't have positionally-exact seeks at all
<dh`> that was far enough before my time that I've never been clear on the details
<dh`> but at least part of the point was you could mount filesystems from them
<TwoNotes> "Block" as opossed to "Character at a time"
<xentrac> sorear: in GPM a macro invocation looked like §swap,zz,bb; where "swap" was the macro name and the arguments were "zz" and "bb"
<TwoNotes> In those days, tyou were very aware of the "block size" of a device. So a disk drive might support a block size of 13,000 bytes because that was one track.
<xentrac> TwoNotes: but you can call write(2) with a byte count larger than 1 on a character special device in Unix too
<TwoNotes> The DMA controller (IBM called it a 'channel') would transfer one block
<sorear> to my limited familiarity with tapes they generally support variable block sizes, as do some old disks
<xentrac> I think the relevant distinction is actually something to do with the kernel buffer cache or something
<TwoNotes> That is just a small matter of programming, with the loop hidden form you
<TwoNotes> But when you filled out the form to preallocate a file, you requested the size in 'blocks', 'trakcs', or 'cylinders'
<TwoNotes> Yes, on a tape you could have variable size blocks. Bigger was better becayuse no inter-block gap wasted space. But you needed buffer size to handle it
<TwoNotes> So if you had 80-byte 'record' (like a punched card!) you might want an integer multiple of 80.
<xentrac> I don't think Unix ever supported preallocating files or specifying offsets in anything other than bytes
<TwoNotes> No, it didn't.. Files were just a stream of bytes. Under the covers of course Unix knoew what the disk was doing, but abstracted it away
<xentrac> right
<TwoNotes> But back then, enitre companies would run their business on a computer with just 256K bytes of memory. No room to waste on fancy file systems
<xentrac> I never realized that maybe the "l" in "lseek" was for "more than 16 bits", sorear :)
mhorne has joined #riscv
<xentrac> you could run Unix in 256KiB
<TwoNotes> I had a summer job at the local electric utility. They ran everything, billing, forecasting, etc, on two IBM computers. One had 256K, the other 32K
<TwoNotes> You could actually run the PL/I compiler in 32KB if you were not in a hurry
<TwoNotes> Typical programming language for the 'business' side was RPG
<sorear> and now we have llseek and mmap2
<xentrac> ugh
<xentrac> TwoNotes: what year was that?
<TwoNotes> hmm. 1970, 71
<xentrac> 32KiB sounds really small for a whole PL/I compiler
<TwoNotes> I didn't say the entire compiler FIT in 32KB. :)
<xentrac> oh, haha
<xentrac> one pass of the compiler fit in 32KiB?
<TwoNotes> Lots and lots of 'overlays'
<xentrac> I don't think even BDS C fit in 32KiB
<xentrac> (the free-software 8080 C compiler)
<TwoNotes> Do one pass, load the next pass, run another pass, load the next pass. Repeat for 30 minutes
<TwoNotes> Off magtape
<TwoNotes> Most of the time, these machines ran in 1401 Emulator mode, I kid you not
<xentrac> yeah
<TwoNotes> The "scheduler" was a human being.
<xentrac> PDP-11 Unix actually wasn't that far off from that, but the passes were separate Unix processes
<xentrac> the PDP-11 couldn't page, so if it didn't have enough core to keep all the passes in core at once, it had to swap out a whole process
<xentrac> so the effect was as if each pass was an overlay, and it would switch back and forth between overlays every time PIPE_BUF bytes had accumulated (I think that was already 8KiB)
<xentrac> so cpp, cc1, maybe cc2?, and as were four separate "overlays" which would be all loaded at once if there was space
<xentrac> maybe someone has used dh`'s tradcpp to compile this stuff more recently
cwebber has quit [Remote host closed the connection]
cwebber has joined #riscv
TwoNotes has quit [Quit: Leaving]
smartin has quit [Quit: smartin]
adjtm has joined #riscv
Bigcheese_ has quit [Remote host closed the connection]
Andre_H has quit [Quit: Leaving.]
choozy has joined #riscv
choozy has quit [Client Quit]